Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mobile-iwg] Recap of Current Scope of Pulsar Galileo
I would like to draw attention to the current progress on Pulsar, and our short term roadmap to the
The initial vision of the User Experience in Pulsar was to give the end-user a simple, guided way to discover and install SDK packages which were pre-qualified to work with the Pulsar IDE package.
The first (Galileo) release was agreed to focus primarily on J2ME developers. 

In order to accomplish this, several things were needed:
a) A pre-configured downloadable IDE package, containing Eclipse + JDT + MTJ + Miscelaneous dependencies. This goal is under way with the help of the Eclipse Packaging Project (EPP).
b) A set of pre-qualified SDK's, which are compatible with the MTJ IDE, most likely using UEI or custom code. Those SDKs were expected to be published by Pulsar member companies on their own company websites, using a Eclipse P2 compliant hosting mechanism. 

c) A "Landing Page", or as we called it, the "Quick Start" feature.
This last item was intended to give the user a choice of SDKs, have pre-configured links to the member company SDK hosting sites, and be the "differentiating" feature of "only Eclipse + MTJ" versus a "Pulsar IDE". The intention was to have this view implemented as either an extension of the Eclipse Welcome Screen, or a more sophisticated "Eclipse perspective" with things like RSS feeds, news readers etc. to create a mobile developer community. Some of those features could have been re-used from existing Eclipse projects, like Mylyn.
As stated on the last conference call, currently the only available "engineering resources" working on Pulsar Galileo are Nokia and Motorola engineers.
The Motorola engineers are finishing up work on MTJ, to deliver a solid "1.0" basis release on which pulsar can be built on. The Nokia engineer(s), see below email, are working on tools for making the creation of the member SDK repositories easier. (to enable step b above.) 


There is currently a VERY HIGH risk around item c, the "quick install" view.
As Dave outlines below, he is not yet actively working on this component.
I would like to remind people that the "official" code-freeze is Monday, May 4th. I have been given a "extension" for another 2 weeks to May 18th, but this is the absolute Drop Dead date. I encourage Nokia to plan a final delivery on Monday, May 11th, giving us one week for final integration, testing and fixing of their code. On Monday, May 18th the first Galileo Release Candidate will be built from the code-base.
My assumption has to be now that we will not be able to create a "fully featured" Quick Install View. Instead, i am looking for "fall-back" proposals from the engineering members (Diego, David, Anyone??) Worst case, we would simply pre-configure the P2 download URLs of the member SDK repositories into the standard Eclipse Update Manager. This would be a inferior user experience, and not deliver the planned user experience. 

Any ideas/code/contributions welcome!

-Christian




David.Dubrow@xxxxxxxxx wrote:



    I am shooting for a first version with a no-frills UI tool to
    generate the repository metadata before the end of May. I believe
    we can have functionality including unzipping zipped sdk archives
    and executing sdk installers done by then. If things go well,
    maybe we can tackle uninstalling within the Galileo time frame
    (which I believe is towards the end of June?), but I don’t know
    how things will go given that we’re still relatively new to P2. It
    seems from my initial investigation, that P2 is doing most of the
    work for us so it’s just a matter of creating the QuickInstall
    view, adding the plumbing between the custom QuickInstall view and
    the P2 wizards and engine code.

    I think we may have a first contribution next week, but it will
    only be engine code with unit test drivers and no UI and no
    metadata generator. After that, I would like to see if it would be
    possible for me to be able to commit directly into the pulsar
    projects at mtj since it would make it easier to backup ongoing
    work. Also, binary contributions (e.g., a test zip archive, or
    test logo image file) are more problematic when it comes to using
    patches as a primary form of contribution. The binaries would have
    to be attached separately with instructions on where to put them,
    etc..

    Lastly, the bugzilla below has been marked resolved by Diego
    because its primary purpose of creating new projects for us is now
    complete. And also, I can’t login to ipzilla – the login page
    states “Only Eclipse committers can use IPZilla.”

    BR,

    --David

Back to the top