| 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 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 From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
On Behalf Of 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: 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 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? Thanks, Doug From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of 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. Craig 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. Ken Wallis Team Lead - Java Development Platform
Tools Research In Motion 905-629-4746 x14369 From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of 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? :) gep From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of 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,
hi
gang, 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. :) gep From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Gang.Ma@xxxxxxxxxx
_______________________________________________ --------------------------------------------------------------------- _______________________________________________ |