Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mobile-iwg] Pulsar participation and dependency on MTJ

I agree with Marks concerns that frequently users equate JME == MIDP, and I agree that we should not limit this version of Pulsar to only MTJ and MIDP development.

The statement about "steering committee approval" is mainly in regards to which "pre-configured SDK URLs" are included. By putting an SDK on the list of "available downloads", we indirectly set a user expectation that there is a reasonable confidence a SDK will "play nice" with Pulsar. In the current version of Pulsar, due to the minimum code we have developed, it is not clear what level if "integration" or "cooperation" between Pulsar and the SDK we can expect.

The "steering committee vote" should therefore not be seen as a exclusion of non-MIDP products, but rather as a "Gating function" to ensure a
well behaved integration.


Reg. PDE inclusion: I will forward this request to the engineering team to see what the impact will be (how many / which plug-ins) and if we can still make the change to EPP.

For future (possible Native C-code etc.) versions of Pulsar, I want to leverage the "P2 dependency resolution" functionality, so we can minimize the number of packages pre-packaged the download, and bring in the rest "on demand", depending on the requirements of the user installed SDK.

-Christian




Mark Rogalski wrote:

I concur with Eric's sentiments. When we discussed the first release of Pulsar being JME focused, I thought that would be ok. But, it seems everyone assumes that JME = MIDP. That is not the case. JME encompasses other JRE's and profiles. BlackBerry is one example and so is eRCP. In the case of eRCP, it is built for JME CDC/Foundation and applications are OSGi bundles. So not only does it not really work with MTJ (in it's present form), but it also need PDE included in the IDE so developers can build bundles. Sorry, I didn't realized PDE was not included in "Eclipse + MTJ" until today. I'm ok with the developer having to switch perspectives for building different types of projects. That is a natural thing in Eclipse anyway.

So, can we put PDE in the Pulsar version of Eclipse? Regardless of the answer, we should also address how developers can easily grow the IDE for new types of projects. Can Pulsar meta data allow the expression of add-on tooling dependencies?




*"Hildum Eric-XFQ473" <XFQ473@xxxxxxxxxxxx>*
Sent by: mobile-iwg-bounces@xxxxxxxxxxx

05/08/2009 10:46 AM
Please respond to
Mobile Industry Working Group <mobile-iwg@xxxxxxxxxxx>


	
To
	"Mobile Industry Working Group" <mobile-iwg@xxxxxxxxxxx>
cc
	
Subject
	RE: [mobile-iwg] Pulsar participation and dependency on MTJ



	





I agree that it is important that a developer have just one copy of Eclipse installed to do all their development. Expanding on this a bit, my experience has been that developers in the mobile space will work serially in different environments to develop an application. That is, they will be given a client project to be completed in J2ME for a large group of phones - LG, Motorola, Nokia, Samsung, Sony Ericsson. Then they will be asked to complete the same client for Blackberry, followed by a native S60 port for Nokia in C/C++. (Windows Mobile and Brew have not shown up in the developments I have seen). The developer will initially download and install the J2ME kit (Eclipse, MTJ, and four or five SDKs), then add RIM's and Nokia's SDKs into their environment, currently by having separate installs. However, they would prefer a single Eclipse environment. Having separate installations causes issues with workspaces and maintaining feature parity across client runtime environments. Pulsar potentially resolves this by allowing a single environment to support all the necessary development - developers simple add additional SDKs as required by schedule. Regarding the steering group comment and allowing RIM on an exception basis. Isn't this a Mobile Working Group? It is not a J2ME Working Group. I don't think inclusion of RIM should be considered an exception. That is, integration with MTJ is not what this is about. As for projects - presumably the project creation wizards will handle setting the correct perspective for non-MTJ projects. We really need the SDKs to be proper plugins, not the short term exe or zip format that exist only to deal with the short deadlines we are currently facing. Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Developer Platforms and Services
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
809 11th Avenue
Sunnyvale, CA 94089
USA
------------------------------------------------------------------------
*From:* mobile-iwg-bounces@xxxxxxxxxxx [mailto:mobile-iwg-bounces@xxxxxxxxxxx] *On Behalf Of *Craig Setera*
Sent:* Friday, May 08, 2009 5:23*
To:* Mobile Industry Working Group*
Subject:* Re: [mobile-iwg] Pulsar participation and dependency on MTJ

As the token "user representative", I think this is an important decision. Having all of my tools in one place is my ultimate goal whether they are MIDP or not. I think it gets a bit more interesting for non-Java environments, but for something like Blackberry, I think this is appropriate.

Craig

On 5/7/09 6:50 PM, Christian Kurzke wrote:
Summarizing a decision from today's conference call:


The Galileo Pulsar package will be a pre-packaged download/install version of Eclipse with MTJ included.

We decided in the call, that the participating (and listed in the quick-install view) SDKs SHOULD integrate with MTJ, but this is not an exclusive criteria.

If an SDK (e.g. RIM) is valuable for Mobile developers, but does not integrate with MTJ (and rather use custom plug-ins extending e.g. JDT), the Steering Committee can grant an exception and allow the inclusion of non-MTJ SDKs in the list of available SDKs.



In this case, the user-experience will be that "Projects" created with MTJ are not compatible with the 3rd party SDK, and the vendor will have to document how to switch from the default MTJ development perspective to the custom SDK perspective (if needed).


-Christian Kurzke


_______________________________________________
mobile-iwg mailing list _
__mobile-iwg@eclipse.org_ <mailto:mobile-iwg@xxxxxxxxxxx> _
__https://dev.eclipse.org/mailman/listinfo/mobile-iwg_ _______________________________________________
mobile-iwg mailing list
mobile-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mobile-iwg

------------------------------------------------------------------------

_______________________________________________
mobile-iwg mailing list
mobile-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mobile-iwg



Back to the top