[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-mtj-dev] The new JAD editor extension point
|
Just open a bug to do it :)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243215
Maybe we can switch the discussion to there and see if we change it or not
:)
gep
-----Original Message-----
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 15:55
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] The new JAD editor extension point
Okay, I think I am less confused ;-)
The current implementation seems to be what we want. The page vendor controls the display via the most appropriate situation for their SDK. Since this is already implemented, I do not see any reason to change it.
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
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Paula Gustavo-WGP010
Sent: Tuesday, August 05, 2008 11:37
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] The new JAD editor extension point
it seems that there is confusion again :)
it is a little confusing, but let me see if i can explain. (gang, feel free to complement since you did the design). It is clear just looking at the code and the extensions definitions
on mtj, we just define an api, org.eclipse.mtj.ui.jadEditor.IVendorSpecTester.isVendorSpec, that each vendor can use to say when his page should be shown. each vendor is able to implement this api on any way he wants. on mtj code we just check for the return of the api to decide on when to show the page.
when this was implemented, it was also provided two examples of how to use the api (as i mentioned, the examples are committed and build separated from mtj runtime code). those two examples show the pages based on the current sdk. there is an api on mtj that we can check the current sdk name and based on that the code return true or false. below is the code that checks for mot
public boolean isVendorSpec(IDevice device) {
Pattern matchPattern = Pattern.compile("nokia*");
Matcher matcher = matchPattern.matcher(device.getGroupName().toLowerCase()); //check current device group name. if it has "nokia" the matcher will return true. And the mage associated with the extension will be shown
return matcher.find();
}
as i mention before, this is just an example on how someone would implement the extension point. if this method is implemented like:
public boolean isVendorSpec(IDevice device) {
return true;
}
The page associated with this extension will always be shown.
So MTJ code DOES NOT filter any page by SDK. It filters the page based on the return of the api that each vendor is suppose to implement and he is free to put any test he wants there.
I like the original design, but, as i said, i'm ok to just remove the filter and always show all pages registered
:)
gep
________________________________
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Raniere Hugo-wha006
Sent: terça-feira, 5 de agosto de 2008 15:29
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] The new JAD editor extension point
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:
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 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?
Thanks,
Doug
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Tuesday, August 05, 2008 9:21 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] The new JAD editor extension point
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/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.
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 Paula Gustavo-WGP010
Sent: Tuesday, August 05, 2008 7:53 AM
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] The new JAD editor extension point
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 Craig Setera
Sent: terça-feira, 5 de agosto de 2008 08:41
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] The new JAD editor extension point
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:
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
Sent: terça-feira, 5 de agosto de 2008 08:25
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,
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
"Sandin Diego-WDS057" <wds057@xxxxxxxxxxxx> Sent by: dsdp-mtj-dev-bounces@xxxxxxxxxxx
2008-08-04 23:34
Please respond to
Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx>
To
"Mobile Tools for The Java Platform mailing list" <dsdp-mtj-dev@xxxxxxxxxxx>
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
Craig Setera <craigjunk@xxxxxxxxxx>
Sent by: dsdp-mtj-dev-bounces@xxxxxxxxxxx
2008-08-04 07:16
Please respond to
Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx>
To
Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx>
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
_______________________________________________
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
_______________________________________________
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
