[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-mtj-dev] MTJ Working Plan
|
Based on the emails, I think that there are two different requirements
to address:
1 - support different profiles and configuration (raised by craig on its
initial email)
2 - increase the flexibility to setup each MIDP/CLDC device
About requirements 1, once we have MTJ 0.9 (based on the proposed
initial planning), it will be possible to add other kinds of platforms
since MTJ will already have the necessary flexibility to do that
(support different projects, wizards, preverification, packing, singing,
mechanisms).
We cannot initially commit to anything outside MIDP/CLDC scope since we
will probably do not have enough resources to do it, but we will be
really happy is some other developer is interested to implement it :)
On requirements 2, there are two different ways to solve it
1 - allow different importers of emulators
2 - have a UI where the user can select which apis are available on each
device
As craig mentioned, current eclipeME defines two extensions called
DeviceImporter and DeviceEditor. To use it, it is necessary to write a
plugin that implements them. The extensions are really flexible and the
implementing plugin must provide a class that represent the SDK device
and another class that knows how to search the SDK install folder and
find all device and create each device SDK specific device.
Those extensions allow that any emulator can "describe itself" listing
all devices and apis that it support. It is a little similar to a
"generic sdk interface" that allow different sdks to be plugged into
eclipseME not only the UEI compliant ones. Of course that the SDK must
implement code in order to provide that functionality.
The second option is also supported by current eclipseME. As eric
mentioned, eclipseME provides a DeviceManager UI, where the user can
edit each device that is associated to it (after one SDK is imported).
On that UI, the user can add, remove or edit any API or JSR that is
supported by the each device. I agree that the UI is not as
user-friendly as WTK one :) and we can work to improve it. But it is
important to highlight that WTK is an SDK not an IDE and what it does is
that it has its own DeviceEditor that change the list of JSRs that is
returned to EclipseME via UEI. So the interface between WTK and
EclipseME is always done via UEI, but WTK SDK provides an interface that
allow their devices to be edited (any other SDK can provide a similar
funcionality)
Current eclipseME DeviceEditor can be used by any SDK that is imported
into eclipseME (not only the UEI ones)
:)
gep
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Wallis
Sent: Wednesday, January 16, 2008 10:05 PM
To: dsdp-mtj-dev@xxxxxxxxxxx
Subject: Re: [dsdp-mtj-dev] MTJ Working Plan
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.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
