< DSDP | MTJ | Discussion | Refactoring
Current Extension Point List
We currently have the following list of Extension points:
- Representation of an Java ME application programming interface (API). In general, an API will be wrapped up within the definition of a JSR.
- Provides a listing of supported Java ME Configurations.
- Provides a means for registering new types of device importers
- Provides a listof supported Java ME Profiles.
- 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.
- Registering an editor for use in editing a device from the device management user interface.
- Add the some JAD attributes to a specific JAD editor page
- Add the some JAD editor pages to the JAD editor.
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
- 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.