Point number 1 is exactly correct.
For point 2, I think the confusion extends around
making manufacturer supplied JAD editor pages context sensitive. If we do so, we
need to figure out a few things:
1) what is the context that enables/disable the
page?
2) how to display the settings when the page is
disabled?
3) how to deal with invalid values from manual changes
while page disabled when page re-enabled.
etc.
It may be a lot easier just to enable the pages at all
times provided we do not have conflicts on the properties managed by the
pages.
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
Hi Guys,
Let me try to split my
opinions according to the different discussions going on
here.
1.
What MTJ is trying to solve?/How MTJ is intended to be
distributed?
In this point I
completely agree with Kens and Craigs view. The user can have an MTJ
installation with several vendor SDKs (and vendor plug-ins extending MTJ). Its
part of the vendor/manufacturer
decision if it will distribute: a) its own customized IDE copy,
containing eclipse, MTJ, its SDK and its specific plug-ins (as Motorola did). Or
b) a set specific plug-ins to be installed on top of a users previous installed
eclipse + jdt + mtj plataform.
Maybe Gustavo has
forgotten this 2nd option because his tighten to the Motorolas
decision of distributing its own customized SDK MOTODEV
Studio.
It is MTJ team responsibility to ensure that
several extensions can fairly co-exist. This led us to the second
discussion.
2.
How will the JAD extension point behave if more than one extension is installed
in a runtime environment?
I think that for a
first solution, all pages that extend this extension point must appear always. I
agree with Craig that will be a lot confusing for the user if he uses a page to
edit a setting and then when he tries to edit again the page doesnt appear
anymore. Furthermore, if I use a vendor specific jad entry, my jad is supposed
to still valid for any other vendor device. There is nothing against the user
having specific entries from different vendors at the same time, so why will we
be hiding and showing pages?
In the future, if it
shows necessary, we can think about including context-sensitiveness (suggested
by Diego) or page managing (suggested by Craig). By now I dont think it is a
high priority requirement.
These were my 2
cents.
J Hugo
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
On Behalf Of Craig Setera Sent: Tuesday, August 05, 2008 10:51
AM To: Mobile Tools for The Java Platform mailing
list Subject:
Re: [dsdp-mtj-dev] The new JAD editor extension
point
I just want to make one related
comment...
I think this discussion is excellent... This thread
proves that people are involved and considering the options. It gives me
hope that the "MTJ reboot" is going to eventually grow into a mature product
with a strong community.
Let's keep the discussions going! (and come to
some decisions <grin> )
On Aug 5, 2008, at 8:49 AM, Gaff, Doug
wrote:
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 havent
been following RIMs 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 RIMs plans around
MTJ?
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/SDKs 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 IDEs 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
_______________________________________________ dsdp-mtj-dev
mailing list dsdp-mtj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|