DSDP/MTJ/Analysis of Extension Points and Plugins Model
MTJ Extension Points
There are 23 extension points defined on the mtj code. Below is an short description of some of them, based on the code (not sure if the information is correct for all of them).
- admin gui provider: main device manager gui admin
- build management: build mtj project
- build provider: returns the steps that needs to be executed in the build process. called by the build manager (currently midp and javame)
- deployment manager: main deploy service
- deployment provider: define the deploy function. called by the deployment manager (currently nokia pc suite)
- device description provider: returns device descriptions (services, configuration, etc)
- device description store: persistence of device description
- device description management: returns all information related to devices. platforms, runtimes, descriptions, etc.
- device platform provider: environment where the device will be executed. provide service to launch a mtj application
- drm encoding provider: ??? (maybe used to represents drm encoded midlet suites???)
- gui builder management: ???
- gui builder provider: ???
- libraries: define all libraries that are supported by mtj
- localization provider: localization to all strings used by the mtj ui
- obfuscation provider: obfuscate on mtj application based an obfuscation configuration
- packing provider: create a deployment packaged
- persistence store provider: general persistence mechanism
- preprocessing provider: used in the fragmentation solution. not clear how
- preverification provider: preverify an mtj project
- screen engine provider: ???
- security management: access a key store. manage information in the key store
- signing provider: sign and unsign mtj project
- ui project: defines the possible types of projects that are supported on mtj (currently javame and midp)
It is important that those extension points are evaluated to identify which ones might be colapsed or removed or if it make sense to keep it in the way that it is. It is clear that most of the above concepts are important, but it might me possible to represent them in a different way.
The below concepts are probably the minimum that need to be somehow represented:
- build provider: the build process might need to be changed
- device platform: the different UEI SDKs need to be abstracted
- deployment provider: there are different deployment mechanism that each manufacturer supports
- obfuscation provider: abstracts the obfuscator that is used (maybe nacessary to also add a UI associated to it)
- libraries: abstract all libraries that are supported by the SDKs or devices (libraries can be configurations, profiles or optional JSRs). (not sure if the profiles and configurations should be listed separately)
- packing provider: there are different packing provider according to the platform (midp 3 packing for instance is a little different than midp 2)
- preverification provider: abstracts the preverification that is used in the MIDP build and packing (not sure if is necessary)
- signing provider: sign and unsign. probably also manage the keystore. (not sure if it will always be the same for different javame profiles)
Is there anything missing?