RE: [dsdp-mtj-dev] MTJ Working Plan

["Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx>]

Hi Gustavo,

Have you started a conversation with Eclipse legal about whether
EclipseME 1.7.7 will pass IP due diligence?

Doug

> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Paula Gustavo-WGP010
> Sent: Tuesday, January 15, 2008 2:46 PM
> To: Mobile Tools for The Java Platform mailing list
> Subject: [dsdp-mtj-dev] MTJ Working Plan
> 
> Hi MTJers,
> 
> Since the end of last year we have been evaluating possible directions
> to go forward with MTJ. One direction that initially seemed to be
> unlikely now appears to be the most technically feasible way to go
> forward. We would like to share it with you and hear your feedback.
> 
> The proposed direction is to use the latest EclipseME (1.7.7 or newer)
> as the code base for the MTJ "reboot". There are a couple of
advantages
> of this approach that are listed below:
> - Eclipse is about communities and EclipseME already has a very large
> user community. This means it has been tested by a large number of
> users
> and we thought that it would be easier to create a developer community
> around it;
> - All major device manufactures today use or point to EclipseME as a
> possible JavaME development environment. With current MTJ code base,
we
> might not be able in a short or medium term to provide a viable
> alternative to EclipseME, and we expect most commercial users, will
> continue to use EclipseME (including Motorola). There is no big user
> nor
> developer community around the current MTJ codebase, and it will be
> really hard to create one if everyone is still using EclipseME
> - Craig Setera will be one of the MTJ committers; the benefits are
that
> he understands deeply the code, and he also has a lot of
> experience/feedback from "real users" about desired future features.
> This very greatly reduces the risk of developing a MTJ 1.0. The goal
is
> to provide a unified community/codebase for EclipseME and MTJ in the
> future.
> 
> We propose the following steps in order to achieve this goal. We can
> break those steps according to some main milestones later:
> - MTJ 0.8 (EclipseME 1.7.7 refactored)
> 	- Refactor all EclipseME code to follow eclipse code standards
> 	- Refactor all EclipseME documentation
> 	- Eclipse Foundation Intellectual Property review on new code
> contribution
> 	- Commit code to Eclipse foundation Subversion / CVS
> - MTJ 0.9 (Increase flexibility)
> 	- Refactor code to break dependencies between UI and Core
> 	- Define a plugin model to support more flexibility. Focus on:
> 	- Pre-verify
> 	- Signing
> 	- Packaging
> 	- Deploying
> 	- Device Manager
> 	- Obfuscation
> 	- Preprocessing
> 	- Include an API layer between UI and Core (possibly with code
> from current MTJ 0.7)
> 	- Define Extension Points to implement the API layer
> - MTJ 1.0 (add back features from MTJ 0.7)
> 	- Refactor and move code from MTJ 0.7 to new code line
> 	- Signing solution
> 	- Import other JavaIDE projects (Netbeans, CarbideJ,
> MotodevStudio)
> 	- MIDlets templates
> 
> MTJ 1.0 will have all features that we plan to include on MTJ first
> release. Items like a "GUI Builder" for Midlets are currently out of
> the
> MTJ 1.0 scope - unless new developers want to join the project and
help
> with the implementation.
> 
> Thanks,
> gustavo
> 
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev