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

["Ken Wallis" <kwallis@xxxxxxx>]

In general yes, this is what I think MTJ would need to maximize the potential target platform base: the ability to specify APIs and point to/import the relevant library.  Being able to do this for an arbitrary API package would be ideal (i.e. Not limited to JSR's), and I assume would not be a stretch over targetting a JSR-only implementation.

Craig, correct me if I am wrong, but the way you set out the EclipseME support below, a plug-in to EclipseME is required in order to add a new device importer?  This would definitely be useful in some scenarios, but I can also see utility in a method where an emulator package could "self-describe" similar to what UEI does (based on Eric's email, I will admit I am woefully uneducated when it comes to UEI and WTK).

Personally, I am not sure how often a developer would want to, or in fact have the appropriate information to be able to, setup a device configuration manually (as alluded to by Eric in reference to the WTK).  I would suspect that a developer would rather point to a provided description of a device, probably packaged with the emulator and associated library.

Good discussion, hope I am making sense.

--------------------------
Sent using BlackBerry


----- Original Message -----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx <dsdp-mtj-dev-bounces@xxxxxxxxxxx>
To: Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx>
Sent: Wed Jan 16 19:38:05 2008
Subject: Re: [dsdp-mtj-dev] MTJ Working Plan

BTW - Much of the functionality you describe is already present in
EclipseME and is broken into appropriate extension points.  It is
possible to register new "device importers" that are consulted to
determine if there is a match against an emulator or something like
that.  Those device importers are required to create device definitions
which in turn include the libraries that are part of each device.  There
is absolutely no reason that (in theory) this functionality could not be
used for the purpose I think Ken is asking for.  That was the reason
that I originally built that functionality.  I'm sure it still has
warts, but I would expect that it would be fairly close to what is
needed for this kind of extensibility.

Paulo... You've looked through the EclipseME code... feel free to comment.

Craig

Hildum Eric-XFQ473 wrote:
> Okay, I think I see what you are driving at.
>
> In the current situation, we are depending on the preconfigured device
> configurations supplied by the UEI compliant SDK to configure the JSRs
> present on the device. Instead, we need a mechanism similar to the one
> in the SUN WTK that allows you to select the JSRs present(the API
> Settings page in the project options).
>
> It appears that this can be done by the device management preference
> panel in EclipseME, but in this case a developer would need to know
> exactly which JSR libraries are available and where to allow that type
> of configuration. I assume that what would be needed is additions to
> allow a new device to be configured and the appropriate libraries to be
> attached to it? Looking at the UEI specification, it appears we should
> be able to get some of the information via the emulator -version command
> and the API Manifest files....
>
> One major difference between the Sun WTK mechanism and what will have to
> be in MTJ is the ability to identify and support multiple manufacturer
> proprietary APIs in addition to the standard ones.
>
> Does this sort of capture it?
>
>
> Eric Hildum
> Senior Product Manager, Mobile Developer Tools & SDK
> Software Platforms and Delivery
> Ecosystem and Market Development
> Motorola
> Direct: +1-408-541-6809
> Mobile: +1-510-305-0801
>
> 809 11th Avenue
> Sunnyvale, CA 94089
> USA
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Wallis
> Sent: Wednesday, January 16, 2008 13:52
> To: Mobile Tools for The Java Platform mailing list
> Subject: RE: [dsdp-mtj-dev] MTJ Working Plan
>
> Hello Eric.
>
> Not really CDC.  Fundamentally, what we would need would be the option
> to configure JSR's.  I believe we are all quite familiar with device
> fragmentation, and it is not an easy problem to solve.  And CLDC/MIDP is
> a great basis that many devices will support, but many devices have
> capabilities beyond that and it would be a shame not to have a plan on
> how to address that.
>
> Timeframe is a harder question to answer. ;)  I am not sure I have a
> particular timeframe in mind.  I think it would be a good selling point
> for a 1.0 release of the tool in order to maximize potential adoption;
> in general the mobile space is seeing more and more attention and a
> target for complex solutions involving sophisticated functionality
> offered by JSR's etc.  If not 1.0 then I would think it should follow
> soon after.
>
> Just my .02 cents from an interested party.
>
> Thanks
>
> Ken Wallis
>
> Team Lead - Java Development Platform Tools Research In Motion
> 905-629-4746 x4369
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Hildum
> Eric-XFQ473
> Sent: Wednesday, January 16, 2008 3:25 PM
> To: Mobile Tools for The Java Platform mailing list
> Subject: RE: [dsdp-mtj-dev] MTJ Working Plan
>
> Ken, Could you give a little more information about what you would like
> to see and when you would like to see it? Are you looking for something
> like CDC support? Would that be something you think should be in prior
> to MTJ 1.0, or could it come a little later?
>
>
> Eric Hildum
> Senior Product Manager, Mobile Developer Tools & SDK Software Platforms
> and Delivery Ecosystem and Market Development Motorola
> Direct: +1-408-541-6809
> Mobile: +1-510-305-0801
>
> 809 11th Avenue
> Sunnyvale, CA 94089
> USA
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Wallis
> Sent: Wednesday, January 16, 2008 11:49
> To: Mobile Tools for The Java Platform mailing list
> Subject: RE: [dsdp-mtj-dev] MTJ Working Plan
>
> Hello everyone.  From our perspective, this would be an essential
> feature in order for developers wishing to target our platform to use
> MTJ.  Our platform supports MIDP and CLDC, but there is a lot more there
> as well; having some way to plug that stuff into the tool would be good.
>
> Thanks for listening. ;)
>
> Ken Wallis
>
> Team Lead - Java Development Platform Tools Research In Motion
> 905-629-4746 x4369
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
> Sent: Tuesday, January 15, 2008 8:30 PM
> To: Mobile Tools for The Java Platform mailing list
> Subject: Re: [dsdp-mtj-dev] MTJ Working Plan
>
> Gustavo,
>
> One thing I think we have failed to consider in our prior discussions is
>
> pulling the current MTJ functionality for configurations and profiles
> outside of CLDC and MIDP.  Depending on input from other groups, I'm not
>
> sure when that should happen, but I do believe we should be pulling that
>
> functionality into the MTJ plan somewhere in the future.
>
> Craig
>
> Paula Gustavo-WGP010 wrote:
>
>> 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
>>
>>
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.