[
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