Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mobile-iwg] Status of Pulsar Eclipse Galileo package

Some other items that need discussed (over email or on Thursday's call):

In general, the EPP packages are built for Windows, Mac OS X, Linux
32-bit, and Linux 64-bit.  This code and overall solution will need to
be tested on all platforms by someone prior to June.

Furthermore, we need a plan for how to handle the fact that all OEM SDKs
will not support all host platforms.  Is the UI code customized for each
host to only display the relevant OEM SDKs or is there a better way of
solving this problem?  What is the easiest solution that results in the
best user experience?

Lori 

> -----Original Message-----
> From: mobile-iwg-bounces@xxxxxxxxxxx 
> [mailto:mobile-iwg-bounces@xxxxxxxxxxx] On Behalf Of Kurzke 
> Christian-E11581
> Sent: Tuesday, May 05, 2009 9:00 AM
> To: Mobile Industry Working Group
> Subject: Re: [mobile-iwg] Status of Pulsar Eclipse Galileo package
> 
> Thanks David for the detailed explanation.
> 
> I understand the schedule pressure, and I think your 
> contribution is a 
> great first step.
> We'll have to now keep working on this, and lay out a roadmap.
> 
> Let's use this as a basis for our call on Thursday.
> 
> Christian
> 
> 
> David.Dubrow@xxxxxxxxx wrote:
> > Hi Christian,
> >
> > I'm afraid I don't have any good news regarding many of 
> your questions. :(
> >
> > First, when I say "install a selected SDK" I mean I will 
> invoke the p2 
> > install wizard on the installable unit for that sdk using 
> the metadata 
> > and artifact repository URLs.
> >
> > Now the bad news:
> >
> > I have not addressed HTTP authentication, and assumed from our last 
> > conference call that repositories would be on open HTTP 
> servers. If p2 
> > does have support for handling authentication, we would 
> need to find 
> > out what we will need to do to enable this support or maybe 
> we might 
> > get it for free, but I have not checked the specific p2 
> requirements.
> >
> > As far as the form of sdk installers, for what I'm doing in this 
> > limited amount of time, two forms are supported - (1) executable 
> > installers which are executed as any other executable might 
> be and (2) 
> > zip archives to be unzipped at the location where the user 
> chooses. As 
> > far as I know, there is no platform dependency since I am 
> using java 
> > to execute a process and the built in p2 native unzip 
> action does not 
> > have any platform dependency. However, I have only tested 
> on Windows 
> > and the unit tests do have a dependency on Windows.
> >
> > I did not make myself familiar with MTJ registration APIs or UEI 
> > compliance because of the lack of time but will be glad to 
> incorporate 
> > any contribution from the MTJ team that could be added in time. I 
> > imagine this would be an action that could be done after 
> installation? 
> > During p2's "configure" phase? If so, p2's action extensions are 
> > relatively simple to develop and I would be happy to give 
> assistance 
> > or point to example code.
> >
> > Finally, there is no support planned in the first release of the 
> > metadata generation tool for installation of OSGi plugins like the 
> > ones you mention for RIM's SDK (I did not know this was needed). In 
> > any case, eclipse plugins are supported by p2's admin tool, and we 
> > should be able to install them, but the p2 metadata would 
> have to be 
> > modified with a few additional properties to be usable in 
> the pulsar 
> > installer view. I could provide support to modify the standard p2 
> > metadata. Alternatively, if they could be provided as a zip 
> file, they 
> > could be unzipped in eclipse's "dropins" directory as a method of 
> > installation.
> >
> > I am sorry about these responses, but we do not have much time to 
> > develop this and all these issues can be addressed for the 
> next release.
> >
> > --David
> >
> >
> > On 5/5/09 9:28 AM, "ext Christian Kurzke" 
> <christian@xxxxxxxxxxxx> wrote:
> >
> >     Hi David,
> >
> >     Thanks for the explanation - this is actually looking 
> better than my
> >     "worst case" assumption I had.
> >
> >     One more question: When you talk about "install a selected SDK",
> >     can you
> >     explain this process?
> >
> >     - Are you assuming a "standard HTTP" style password 
> protection of
> >     the P2
> >     repository? (HTTP Basic or Digest authentication over 
> HTTP or HTTPS)
> >     - Is the IDE using P2 authentication dialogs, or were 
> you able to
> >     replace those?
> >
> >     further more:
> >     What is the packaging format of the "SDK"?
> >     - is the SDK contained in an executable format? (which 
> host Operating
> >     Systems does your plugin support)
> >     - after the SDK is downloaded and installed, do you use 
> the new "MTJ
> >     device registration" APIs?
> >     -- How will Eclipse know the path of the SDK?
> >     -- Do you assume UEI compliance.
> >
> >     - Would this technically also support an SDK like RIM, which is
> >     currently distributed as a set of multiple Eclipse 
> Plugins (and not a
> >     stand alone UEI executable)
> >
> >     Thanks again!
> >
> >     -Christian
> >
> >
> >     David.Dubrow@xxxxxxxxx wrote:
> >     > Hi Christian,
> >     >
> >     > I just wanted to clarify the status of the "quick 
> install view." You
> >     > are correct that there is not enough time to 
> implement the full
> >     > visually appealing version shown in the use case 
> discussion wiki
> >     page,
> >     > however, I am planning a pulsar specific view that 
> will unfortunately
> >     > be a lot more utilitarian and less flashy given the 
> amount of time I
> >     > have to implement it.
> >     >
> >     > * It will be an eclipse view with a table tree showing
> >     > repositories, optional categories and sdks in a multiple root
> >     > tree in one column and sdks' installed status on the 
> other column.
> >     > * Top-level nodes denoting sdk repositories will be 
> able to have
> >     > icons but they need to be limited to 16x16 so they look
> >     > reasonable in a tree view.
> >     > * Since only install is supported, there will be one 
> view action
> >     > (toolbar and menu) to install a selected sdk.
> >     > * Sdks will show installed status, but will not be 
> prevented from
> >     > being installed multiple times because we are not 
> supporting nor
> >     > tracking uninstalling in this release due to lack of 
> development
> >     > time.
> >     > * The view's install action will open a standard p2 
> install wizard
> >     > with support for EULA acceptance if the EULA is provided with
> >     > the metadata.
> >     >
> >     >
> >     >
> >     > --David
> >     >
> >     >
> >     > On 5/4/09 10:45 PM, "ext Christian Kurzke"
> >     <christian@xxxxxxxxxxxx> wrote:
> >     >
> >     > As I explained in the email last week, we had today 
> the "official"
> >     > code-freeze for the Eclipse Galileo build.
> >     >
> >     > For MTJ/pulsar, I have been granted a 2 week extension for our
> >     > code, but
> >     > - i think we have a very good idea now what the final 
> package will
> >     > look
> >     > like, and engineering is working hard to make the 
> final deliveries.
> >     >
> >     > In this weeks meeting I would like to go over the 
> current status
> >     > of the
> >     > work. Hopefully Diego (Motorola) and David (Nokia) 
> can give a brief
> >     > status report.
> >     >
> >     > My understanding is that due to the lack of a 
> official Pulsar "quick
> >     > install view", we will not be able to have a 
> "friendly" guided SDK
> >     > discovery and download UI, as initially planned. (see here for
> >     initial
> >     > proposal:
> >     > 
> http://wiki.eclipse.org/EMIWG/MADKQuickStartUseCasesDiscussion)
> >     >
> >     > Instead we will only be able to deliver a "P2" user 
> experience with
> >     > preconfigured links to the individual company repositories.
> >     > For an overview of this UI flow, see:
> >     > http://wiki.eclipse.org/Equinox_p2_UM_workflows (note, this is
> >     > Equinox, but the Galileo will be very similar)
> >     >
> >     > One of the biggest deficiencies will be the handling 
> of "user account
> >     > creation". If a user is not already signed up at any of the
> >     > participating "Developer Programms", and the P2 URL 
> is password
> >     > protected, then the download will fail, and there is no option
> >     > given for
> >     > the user to sign in.
> >     > It may in fact not even be clear to the user WHICH 
> password he is
> >     > prompted for. (the P2 Log-In Dialogs are very sparse)
> >     >
> >     >
> >     > Please bring creative ideas to the meeting on 
> Thursady how we can
> >     > address this issue.
> >     >
> >     > -Christian
> >     >
> >     >
> >     > _______________________________________________
> >     > 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
> >
> > 
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > 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