[
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