DSDP/MTJ/Discussion/Refactoring/EP

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.