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 Ken’s
and Craig’s view. The user can have an MTJ installation with several vendor
SDKs (and vendor plug-ins extending MTJ). It’s 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 user’s previous installed eclipse +
jdt + mtj plataform.
Maybe Gustavo has forgotten this 2nd
option because his tighten to the Motorola’s 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 doesn’t 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 don’t 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 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?
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
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|