Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/MTJ/Discussion/Refactoring/EP"

< DSDP‎ | MTJ‎ | Discussion‎ | Refactoring
(Refactory Suggestions)
(Current Extension Point List)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Current Extension Point List ==
+
== MTJ 0.9.1 Extension Point List ==
  
We currently have the following list of Extension points:
+
We had the following list of Extension points in MTJ 0.9.1:
  
 
* '''org.eclipse.mtj.core.api'''
 
* '''org.eclipse.mtj.core.api'''
Line 10: Line 10:
 
** Provides a means for registering new types of device importers
 
** Provides a means for registering new types of device importers
 
* '''org.eclipse.mtj.core.profiles'''
 
* '''org.eclipse.mtj.core.profiles'''
** Provides a listof supported Java ME Profiles.
+
** Provides a list of supported Java ME Profiles.
 
* '''org.eclipse.mtj.core.library.MIDletLibrary'''
 
* '''org.eclipse.mtj.core.library.MIDletLibrary'''
** Define the concept of MIDlet suite library. An external library (not JSR from SDK) that may be used in a midlet. For example a Database Access support library.
+
** Define the concept of MIDlet suite library. An external library (not JSR from SDK) that may be used in a MIDlet. For example a Database Access support library.
 
* '''org.eclipse.me.ui.deviceEditor'''
 
* '''org.eclipse.me.ui.deviceEditor'''
 
** Registering an editor for use in editing a device from the device management user interface.
 
** Registering an editor for use in editing a device from the device management user interface.
Line 21: Line 21:
  
 
== Refactory Suggestions ==
 
== Refactory Suggestions ==
 +
  
  
Line 34: Line 35:
 
       for MIDP/CLDC projects anyway.</b></font>  
 
       for MIDP/CLDC projects anyway.</b></font>  
  
 +
    '''org.eclipse.mtj.ui.venderSpecJADAttributes'''
 +
    '''org.eclipse.mtj.ui.jadEditorPages'''
 +
        <font color="#960018"><b>We could merge this two E.P. we always implement both of them to add a new
 +
        page anyway.</b></font>
 +
 +
 +
== Other Options, Opinions, etc ==
 +
 +
<font color="#960018"><center><b>[ Please, contribute with this discussion ]</b></center></font>
 +
 +
* [Craig] I think we should seriously look at collapsing the API, MIDLETLibrary, Configuration and Profile extension points.  An API may be a configuration or profile (or not).  The difference between an API and a MIDLetLibrary sounds like it is only whether one is in a JSR and one is not.  That could really be attributes on a single extension point.
 +
** I don't think we can remove the idea of an API/Library... While UEI allows that information to be queried, we need some place to store the information and we also want to be able to continue to support non-UEI.
 +
* '''[Diego]''' I believe that API and library may not be collapsed. The Library E.P requires a lot more information than the API E.P such as licensing information, access rules,  javadoc, sources and so on. Please, check the [http://wiki.eclipse.org/DSDP/MTJ/Requirements/Library_Support library support requirements] to see the full list.
 +
 +
 +
----
 +
 +
* [Craig] I thought the idea of the vendor specific attributes was to be able to add an attribute to an existing page?  If so, they can't really be merged.  I'm OK with the split, but I do think the extension point's name should be spelled out rather than the short version being used currently.
  
 
[[Category:DSDP]] [[Category:MTJ]]
 
[[Category:DSDP]] [[Category:MTJ]]

Latest revision as of 10:15, 11 March 2009

MTJ 0.9.1 Extension Point List

We had the following list of Extension points in MTJ 0.9.1:

  • org.eclipse.mtj.core.api
    • Representation of an Java ME application programming interface (API). In general, an API will be wrapped up within the definition of a JSR.
  • org.eclipse.mtj.core.configurations
    • Provides a listing of supported Java ME Configurations.
  • org.eclipse.mtj.core.deviceImporter
    • Provides a means for registering new types of device importers
  • org.eclipse.mtj.core.profiles
    • Provides a list of supported Java ME Profiles.
  • org.eclipse.mtj.core.library.MIDletLibrary
    • Define the concept of MIDlet suite library. An external library (not JSR from SDK) that may be used in a MIDlet. For example a Database Access support library.
  • org.eclipse.me.ui.deviceEditor
    • Registering an editor for use in editing a device from the device management user interface.
  • org.eclipse.mtj.ui.venderSpecJADAttributes
    • Add the some JAD attributes to a specific JAD editor page
  • org.eclipse.mtj.ui.jadEditorPages
    • Add the some JAD editor pages to the JAD editor.

Refactory Suggestions

   org.eclipse.mtj.core.api 
    * Are we the only ones that implements this E.P?
    * Is it really necessary? since the UEI standard provides a way to gather the APIs from a SDK's device
    * The skeletonFile element is not used anymore
   org.eclipse.mtj.core.configurations
   org.eclipse.mtj.core.profiles
      Does these are really necessary? we are the only ones that implements it, 
      and the values are very standardized, we could use directly from the code. It only works 
      for MIDP/CLDC projects anyway. 
   org.eclipse.mtj.ui.venderSpecJADAttributes
   org.eclipse.mtj.ui.jadEditorPages
       We could merge this two E.P. we always implement both of them to add a new
       page anyway. 


Other Options, Opinions, etc

[ Please, contribute with this discussion ]
  • [Craig] I think we should seriously look at collapsing the API, MIDLETLibrary, Configuration and Profile extension points. An API may be a configuration or profile (or not). The difference between an API and a MIDLetLibrary sounds like it is only whether one is in a JSR and one is not. That could really be attributes on a single extension point.
    • I don't think we can remove the idea of an API/Library... While UEI allows that information to be queried, we need some place to store the information and we also want to be able to continue to support non-UEI.
  • [Diego] I believe that API and library may not be collapsed. The Library E.P requires a lot more information than the API E.P such as licensing information, access rules, javadoc, sources and so on. Please, check the library support requirements to see the full list.



  • [Craig] I thought the idea of the vendor specific attributes was to be able to add an attribute to an existing page? If so, they can't really be merged. I'm OK with the split, but I do think the extension point's name should be spelled out rather than the short version being used currently.

Back to the top