RES: [mobile-iwg] Pulsar participation and dependency on MTJ

["Paula Gustavo-WGP010" <wgp010@xxxxxxxxxxxx>]

Current pulsar package already includes PDE. I'm doing some tests today
on it

The download size is 120 MB

:)
Gep (back from vacation)

-----Mensagem original-----
De: mobile-iwg-bounces@xxxxxxxxxxx
[mailto:mobile-iwg-bounces@xxxxxxxxxxx] Em nome de Kurzke
Christian-E11581
Enviada em: segunda-feira, 11 de maio de 2009 14:08
Para: Mobile Industry Working Group
Assunto: 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
>   

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