My 2 cents:
What you are discussing is vendor neutrality. This is a
requirement for eclipse projects to graduate out of incubation. In other words,
in order for MTJ to reach 1.0, the project will need a demonstrable adoption
community that includes more than one vendor.
Ken, I haven’t been following RIM’s participation lately, but I
hope you guys are engaging in the project now. I guess you know this already,
but if you want MTJ to work with RIM devices (I would very much like that), RIM
needs to be working on that integration. Can you update me on RIM’s plans
around MTJ?
Thanks,
Doug
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Craig Setera
Sent: Tuesday, August 05, 2008 9:21 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] The new JAD editor extension point
Ken, I think I agree with you... that this should be a tool
that users can use out of the box to target multiple vendors with little or no
effort. In addition, they should be able to switch "emulators"
easily and test against lots of devices. That was the goal of EclipseME
and I want to make sure that continues in MTJ.
With that said, I think we are dealing with two separate
topics in this thread:
1) What do the API's and extension points support?
2) How are the extensions packaged?
I can see the extension point supporting any vendor's
extensions, while not having those extensions necessarily shipped as part of
the default MTJ installation. I would expect, however, that those
extensions would be available and installable into MTJ without having to
download the complete MotoDev Studio or RIM development environment.
That is my opinion of where I hope we are heading.
On Aug 5, 2008, at 8:14 AM, Ken Wallis wrote:
This thread has really got me thinking about my on assumptions what
problem MTJ is trying to solve. I had assumed that MTJ would be a
platform which ME developers could use to create applications, and which could
be extended by manufacturers for manufacturer specific concepts/SDK’s
etc. So far so good. But I had also assumed that
manufacturer-specific extensions could co-exist on top of the same MTJ
instance. ME developers could then have only one “IDE” and be able to
target specific manufacturers from within that single IDE.
Now, based on this discussion, it sounds like this is not the major
concept of MTJ as I understood it. Is it intended that MTJ is more of a
runtime that is not intended to stand on its own, and it is expected to only be
bundled into a “proprietary” IDE targeting a specific manufacturer? ME
developers would then still have to manage multiple IDE’s for every
manufacturer they want to support?
Please let me know if I understand correctly. It certainly
seems like this needs to be clarified for the purposes of this specific
discussion as well, as it would certainly lead us in different directions for
how to support custom JAD editor extensions.
Team Lead -
Java Development Platform Tools
ok... let me return to my original comment :)
by default mtj runtime will never have any vendor specific page on
the jad editor (at least this is the current design). the only place that it
will appear would be in a nokia IDE that distribute mtj and only if nokia
decide to implement the jad editor extension point and add their own page. in
this scenario, maybe it is not bad that the nokia page is shown with a nokia
sdk and, if the user decide to use the same nokia IDE to develop to motorola,
the page will not be shown (actually the page is not even in that
distribution :)).
so i think that probably those changes that we are discussing
make more sense only if we decide to move the vendor specific pages to
MTJ runtime and maintain that code inside MTJ. does that make sense
to everyone?
Perhaps it is time to add some new
UI to control the JAD editor? A preference page that lists the available
pages and allows them to be turned on and off? For instance, if I never
want to make vendor-specific changes, I could go into the preferences and
deselect those pages? Even better would be if the pages could be closed
from the editor and then reenabled from the preferences. That would solve
these issues because it would be an explicit action on the part of the user.
On Aug 5, 2008, at 6:36 AM, Paula
Gustavo-WGP010 wrote:
the problem is that the vendor that diego mentioned is not the
device manufacturer. this field on the jad is the midlet suite developer (like
gameloft, EA games, etc.). since that, i don't think that we make the
nokia, mot, etc pages context sensitive based on this information.
Hi,
I think Diego's suggestion that make the vendor specific page be context sensitive can avoid the confusion Craig described, need
we do like that?
Best Regards
Gang(Allen) Ma
2008-08-04
23:34
|
To
|
|
cc
|
|
Subject
|
RE:
[dsdp-mtj-dev] The new JAD editor extension point
|
|
Hi
everyone,
Maybe
we can have a 4th option.
We could set the vendor specific page to be context sensitive to the attributes
available in the Application Descriptor.
For
instance, if a Motorola or Nokia vendor attribute is in the Application Descriptor,
we add the vendor page that can handle that attribute. If the attribute is
unknown to any vendor that implemented the venderSpecJADAttributes Extension Point it can be displayed in
the User Defined page
We
could also add an action “Add Vendor Specific JAD Attribute” that would open a list of all
Vendor Specific JAD Attributes, and after the user select the ones he want, the
vendor pages are displayed automatically in the editor.
Regards
Diego
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Paula Gustavo-WGP010
Sent: Monday, August 04, 2008
11:04 AM
To: Mobile Tools for The Java
Platform mailing list
Cc: dsdp-mtj-dev-bounces@xxxxxxxxxxx
Subject: RE: [dsdp-mtj-dev]
The new JAD editor extension point
hi craig,
actually it is really nice to have you very active on the list.
about the jad editor... actually I committed the code on svn
without any of the extensions implementations. all extensions implementations
(nokia and mot) are on MTJ examples (just to give an idea on how to use the
extension). so by default the user will not see any vendor specific page on MTJ
runtime / sdk.
the original idea is that each vendor would be able to pack MTJ
with its own extensions and provide an environment that is suppose to target
only its own devices. i see three options
1- keep this original idea (mtj runtime all not shown any vendor
specific page)
2- move nokia and mot specific extensions to MTJ runtime and keep
current code (mtj runtime will show nokia / mot specific pages, based on
current SDK)
3- move nokia and mot specific extensions to MTJ runtime and change
code to shown all vendor specific pages (mtj runtime will show both nokia and
mot pages)
i tend to like current solution designed and implemented by gang,
but i'm open to change my mind.
:)
gep
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Gang.Ma@xxxxxxxxxx
Sent: domingo, 3 de agosto de
2008 22:48
To: Mobile Tools for The Java
Platform mailing list
Cc: Mobile Tools for The Java Platform mailing
list; dsdp-mtj-dev-bounces@xxxxxxxxxxx
Subject: Re: [dsdp-mtj-dev]
The new JAD editor extension point
Hi Craig,
In the scenario you described, the Motorola attributes will be shown on the
User Defined page, and he/she can change them there. If he/she switches back to
Motorola SDK, the defined Moto-specific attributes will still be shown on the
Motorola page, and the nokia-specific attributes will be shown on the User
Defined page.
Is it ok for that?
Thanks!
Best Regards
Gang(Allen) Ma
email: gang_ma@xxxxxxxxxx
2008-08-04
07:16
|
To
|
|
cc
|
|
Subject
|
[dsdp-mtj-dev]
The new JAD editor extension point
|
|
I apologize to everyone for the email "spam" today. That's what
happens
when I do all of my MTJ work in one marathon session!
I took a look at the new JAD editor extension point functionality today
and I'm good with the code. I am a bit concerned about the ability to
configure a vendor-specific filter for the pages though. Imagine a user
scenario that looks like this:
- Developer starts by using a Motorola-based SDK, which causes the
Moto-specific JAD editor page(s) to be added to the editor.
- Developer configures some Moto-specific JAD attributes using the
vendor-specific editor page(s)
- Developer switches to a Nokia-based SDK, which causes the
Nokia-specific editors page(s) to be added the Moto pages to be *removed*
- Developer alters the Nokia specific attributes and wants to make a
change to the Motorola attributes as well... *but can't find them*
While I understand the idea of not forcing the user to see pages that
don't apply for the current device, it feels to me like the pages should
be shown no matter what if there are vendor-specific attributes that
have been altered. One option is to always show all pages. The
other
is to show pages that apply to the current SDK *and* those that have
been previously shown.
I'd appreciate thoughts.
Thanks,
Craig
_______________________________________________
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
|