How easy is it to write a new Touchpoint to run some Java code
(of ours) after everything is downloaded? Any examples? We are sophisticated plugin
writers. I’ll read http://wiki.eclipse.org/Equinox_p2_Touchpoint_Instructions.
Looking for any examples and “extension points”.
Thank you for the guidance.
farokh
From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of Susan Franklin McCourt
Sent: Monday, August 04, 2008 1:46 PM
To: Equinox development mailing list
Cc: equinox-dev@xxxxxxxxxxx; equinox-dev-bounces@xxxxxxxxxxx
Subject: 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>
|
|
"Farokh
Morshed" <fmorshed@xxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
08/04/2008 09:04
AM
Please respond to Equinox development mailing
list
|
To: <equinox-dev@xxxxxxxxxxx>
cc:
Subject: [equinox-dev] Does Eclipse support
native installation scenarios?
|
Our problems with adopting P2 is mounting. I am starting to doubt whether P2 in
3.4 is really ready for prime time or at least our use.
Use case: We want the user to launch our plugin’s installation process by
simply clicking “Install…” in the Software Updates view. This action would
download the plugin and a native installation executable (a window’s MSI exe
file). Then, the native installation executable would be launched, user
interacts with the native installation process, and upon completion of the
native installation process the installation of the plugin proceeds. If
something goes wrong during the native installation, or user simply changes his
mind and cancels, we don’t want the plugin to be installed at all.
But it appears that P2 has no way for us to launch the native installation executable.
We have also thought about launching our native installation executable upon
first use of the plugin. We certainly would not want to do this in the plugin’s
start method. That would violate the etiquette that plugin start method take a
very long time. So, we would leave this initialization for after the start
method, to the actual use of our plugin. But, what if the installation failed.
What if the user changed his mind and decided not to install at all. How do we
tell Eclipse that this plugin is “dormant” and should be uninstalled by the
user, you know, something similar to how Eclipse behaves after a plugin start
method has raised an exception. Looks like we cannot just call the plugin’s
stop method, the Plugin’s stop method comment says “Clients must never explicitly call this method”.
I feel like we are between a rock and a hard-place, or totally missing
something.
My questions are:
1) Is the use case above a
“reasonable” use case in the eyes of the P2 project?
2) Is the use case above supported in P2 now?
3) If not, will it be supported very soon?
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?
By the way, we will always have this native installer. Eliminating the native
installation is not an option for us.
If this mailing list is not the proper place to discuss this matter, PLEASE
tell us so. Thank you.
farokh _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
