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
(Other Options, Opinions, etc)
(Other Options, Opinions, etc)
Line 44: Line 44:
 
== Other Options, Opinions, etc ==
 
== 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.
 
* [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.

Revision as of 09:43, 1 February 2009

Current Extension Point List

We currently have the following list of Extension points:

  • 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 listof 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