DSDP/MTJ/Discussion/Refactoring/api

From Eclipsepedia

< DSDP‎ | MTJ‎ | Discussion‎ | Refactoring
Revision as of 16:07, 2 February 2009 by Wds057.motorola.com (Talk | contribs)

Jump to: navigation, search

New API structure

  • After analyzing the current API, it was found that most of classes that are public are not necessary and can be moved to the internal api package.
  • Some refactory should be done to remove MIDP methods and attributes from the more common interfaces, for example IDevice, and make them more generic,


   org.eclipse.mtj.core
       + build [ all classes and interfaces related to build tasks ]
           + preverification
               + MIDP
                   - StandardPreverifierFactory
                   - StandardPreverifierParameters
                   - StandardPreverifier
               - IPreverifier
               + preprocessing
                   - ISymbolDefinitionSetChangeListener
                   - SymbolDefinition
                   - SymbolDefinitionSet
                   - SymbolDefinitionSetRegistry
               + sign
                   + MIDP
                       - midp especific classes and interfaces
                   - ISignatureProperties
                   - SignaturePasswords
                   - SignatureProperties
               + deploy
               - IBuildConsoleProxy
               - BuildConsoleProxy
               - MTJBuilder
       + persistence [classes managing persistence]
            - IPersistable
            - IBundleReferencePersistable
            - IPersistenceProvider
            - PersistableUtilities
            - PersistenceException
       + project [ all classes and interfaces related to a MTJ project ]
           + MIDP
               - IMidletSuiteProject
               - IMidletSuiteProjectListener
               - MidletSuiteFactory
           - IMTJNature
           - MTJProjectConverter
           - MetaData
           - ProjectConvertionException
       + sdk
           + device
               + MIDP
                   - IMIDPDevice [ Extend IDevice and add MIDP specific aspects ]
                   - ILaunchConstants
                   - LaunchEnvironment
               - IDevice [ Create a basic device spec, with out the MIDP aspects ]
               - IDeviceImporter
               - ILaunchEnvironment
       - ISDK [ Some information available in each device are replicated and refers to the sdk info]
               [ this informations could be added to a SDK class that would aggregate all devices ]
       - IBaseModel
       - IEditable
       - IModel
       - IModelChangedEvent
       - IModelChangeProvider
       - IModelProvider
       - IModelProviderEvent
       - IModelProviderListener
       - IResourceFilter
       - IWritable
       - MTJCore  [ follow the same concept as JDT, and externalize some aspects by this facade, instead of so many classes ]
                     [ For example, check if a certain nature is available.]
       
   org.eclipse.mtj.toolkit.uei [ No API needed could turn it into internal ]
   org.eclipse.mtj.core.library [ Implementations can be moved to internal, they are not necessary to be public ]
                [ only models need to be public but must use API Restrictions such as @noimplement ]
        + security
            Permission
            PermissionList
            SecurityInfo
        - MidletLibrary
        - ProtectionDomain
        - ILibrary
        - Visibility
   org.eclipse.mtj.ui [ Most of packages are not really an API, can be moved to internal ]
        + editors
            + device [ required by implementors of device importer E.P ]
            + jad    [ required by implementors of jad vendor specific  E.P ]

Other Options, Opinions, etc

[ Please, contribute with this discussion ]
  • [Craig] I'm fine with reducing the visibility of any class that we can "get away" with to avoid usage where we don't want it. It is far easier to add access later than to remove it.
  • [Craig] I agree with the idea of splitting the MIDP-specifics out in the model. I think that makes a lot of sense.
  • [Craig] I think we might still want to mark some of these classes that are public as provisional until we get more feedback from other vendors.
  • [Craig] ProjectConvertionException should be ProjectConversionException