| 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 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@xxxxxxxxxx2008-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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|
