| Re: [equinox-dev] Does Eclipse support native installation scenarios? |
Hi, Farokh.
Most (all?) of the p2 core team are taking their vacations right now. I work on the UI for p2, so while I use the core API, I don't know the exact state of the underlying implementation and what limitations are there in 3.4 as well as those guys do. So consider this answer as a bit of hand-waving and later in the week someone can fill in more detail and your follow-on questions.
>1) Is the use case above a “reasonable” use case in the eyes of the P2 project?
The short answer is that the p2 architecture is exactly designed to support scenarios like this. One of the reasons for building a new provisioning infrastructure was to support scenarios that have nothing to do with Eclipse plug-ins and features, and handle support for native installs, downloading and installing non-Java artifacts, etc. etc.
>2) Is the use case above supported in P2 now?
Not without writing some code, and I'm not sure what else would have to be done on the p2 side. The focus for 3.4 was to be able to replace the existing update manager, so much of our focus in that release was on the simpler Eclipse install scenarios. You may have read about p2's lack of support for UM "install handlers." For 3.4, we simply ran out of time to cover the more advanced UM scenarios. So while our architecture supports custom installs at a much more granular level than UM did, what I describe below may not have been tried yet, and there may be bugs/limitations/etc. that we would have to fix for this to work. (The core guys could provide much more detail about where we are at exactly...)
The basic idea is that an installable unit (IU) can define "touchpoints" that run at different phases of the install process. p2 has implemented touchpoints for Eclipse plug-in operations and some native file operations. Third parties can register their own touchpoints.
In your scenario, you would define metadata representing your plug-in and the native executable. The user selects the IU that represents your product and presses "Install...". At this point, the user interacts with the p2 UI (where any licenses would be approved and so forth). This causes the plug-in and installation file, and any other pieces necessary, to be downloaded (by virtue of your metadata defining the pieces that are required). As your IU passes through the install phases, it goes through several phases (download, install, configure). At each of these phases, the "touchpoints" can be run. Your touchpoint would run the executable, thus launching your UI. When your install was completed, the touchpoint would return and the rest of the p2 phases would continue until the user was prompted for restart, etc.
There is some documentation on the existing touchpoint implementations at:
http://wiki.eclipse.org/Equinox_p2_Touchpoint_Instructions
>3) If not, will it be supported very soon?
The 3.4.1 and 3.5 plans are not finalized. The lack of install handlers is a blocker for many products that otherwise want to adopt to p2. So I would expect something to happen early in the 3.5 cycle, but I can't promise anything until we have plan. Note that the API is all provisional in 3.4 and an important part of 3.5 is to work with a wide variety of install use cases to make sure we handle them.
>4) Should we abandon P2 and use the old update manager for the foreseeable feature and count on P2 to support this use case BEFORE the old update manager is deprecated?
If update manager install handlers support your needs, then I think it's safe to assume that our touchpoint support would support your scenario before UM is deprecated. I would imagine that we would either:
a) define a touchpoint that knows how to deal with UM install handlers in some backward compatible way. I'm not sure if this is possible or not, depending on what assumptions were made by preexisting install handlers with respect to the underlying file structure, etc.
b) define a specific migration guide that explains how to use touchpoint actions to accomplish what was previously done in the install handler.
That said, if your product timeline allows you to work with us on this scenario rather than waiting for it to be completed, it will help to ensure that the evolving API meets your requirements.
I hope this helps...
susan
"Farokh Morshed" <fmorshed@xxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx 08/04/2008 09:04 AM | To: <equinox-dev@xxxxxxxxxxx> cc: Subject: [equinox-dev] Does Eclipse support native installation scenarios? |
