Point 2: It doesnt
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
dont overlap.
Hugo
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
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
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
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
_______________________________________________