Point 2: It doesn’t make sense to me
to filter by SDK, as it will be confusing for the user if he changes the device
associated with the project and pages appear/disappear.
When I mentioned context-sensitiveness, I
meant the suggestion raised by Diego, that is my understanding is: CONTEXT is
not the SDK, is the actual JAD contents. Extensions (vendor pages) will be
associated with certain jad properties, if the related properties are in the
JAD, the page must appear. Moreover, there will be a mechanism in place to add
vendor-specific properties to the page and make the related page appear. I
think this solution is even better to handle the situation of the vendor declaring
more than one extension/page. The problem will be to ensure that the ser of
properties related to each page don’t overlap.
Hugo
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Hildum Eric-XFQ473
Sent: Tuesday, August 05, 2008
2:39 PM
To: Mobile Tools for The Java
Platform mailing list
Subject: RE: [dsdp-mtj-dev] The
new JAD editor extension point
Point 1: MTJ should not have vendor
specific code. That should be left to vendors. We can supply a Motorola handset
specific page, but that will not be part of MTJ, it will be part of MOTODEV
Studio for Java ME.
Point 2: I am confused here. How would we
filter by SDK? I am assuming that a developer is in a project and is editing
the JAD file in that project. Are we filtering based on the device/SDK
associated with the current project at the time the JAD editor is invoked? If
so, what happens if the developer changes the device associated with the
project while the editor is invoked?
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
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Paula Gustavo-WGP010
Sent: Tuesday, August 05, 2008
10:26
To: Mobile Tools for The Java
Platform mailing list
Subject: RE: [dsdp-mtj-dev] The
new JAD editor extension point
i'm also enjoying a lot the discussions...
and if we are discussing, it means that we are on the right direction
based all emails, it seems that there are
two main questions to discuss:
1 - do we want to have the vendor specific
pages as part of MTJ runtime or leave this job to each vendor?
2 - if there are more then one vendor jad
extension installed on one eclipse distribution (eclipse + jdt + mtj), do we
want to show all of then at the same time or provide the option to filter by
sdk
about issue 1, currently we are not
including any vendor specific extension inside MTJ runtime. there are just part
of MTJ examples. i think that it makes more sense to leave to leave like that,
otherwise we will have problems like:
- which vendor to support inside mtj?
- how to update the properties based on
new properties added by the vendor?
- most of all, based on doug's email, we
need to be vendor neutral inside eclipse
maybe we can host some extensions
externally... or provide then in a separated download... but if we decide to do
that, we will also have to maintain this.
about issue 2, current api
design gives the option to filter based on the sdk. it is important to
note that each vendor can just return TRUE on the
org.eclipse.mtj.ui.jadEditor.IVendorSpecTester.isVendorSpec
this will make his page to always be shown. the examples
that were include are doing the check based on the sdk, but it is just to
illustrate how to do it... but if we think that this api should be removed, i'm
ok with that.
i'm not sure if this summarizes everything... feel free to
add more question otherwise we can comment on top of those two issues.
:)
gep
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Hildum Eric-XFQ473
Sent: terça-feira, 5 de agosto de
2008 13:55
To: Mobile Tools for The Java
Platform mailing list
Subject: RE: [dsdp-mtj-dev] The
new JAD editor extension point
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
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Raniere Hugo-wha006
Sent: Tuesday, August 05, 2008
8:21
To: Mobile Tools for The Java
Platform mailing list
Subject: RE: [dsdp-mtj-dev] The
new JAD editor extension point
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