Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top