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 
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

Back to the top