Thanks Susan. Before I delve into this, can you tell if, even
in the best case scenario, we would have to contribute code to the Touchpoint
stuff and hence wait for a feature release of Eclipse to be able to do what we
want? If this is the case, we have to make different plans for our release (go
to some plan B). We don’t mind contributing code, but we also must make our own
release plans.
BTW, should I be sending mail to both the mail addresses above?
farokh
From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of Susan Franklin McCourt
Sent: Monday, August 04, 2008 4:39 PM
To: Equinox development mailing list; p2-dev@xxxxxxxxxxx
Cc: 'Equinox development mailing list'; equinox-dev-bounces@xxxxxxxxxxx
Subject: RE: [equinox-dev] Does Eclipse support native installation
scenarios?
You can start by looking at:
org.eclipse.equinox.p2.tests - the plugin.xml registers two test touchpoints
org.eclipse.equinox.internal.provisional.p2.engine.phases - the Install class
defines actions that run before and after other actions defined in the install
phase. This is where the install related events are sent. Presumably your
touchpoint action would run in the install phase, so this is a decent example
for gathering some of the parameters that might be needed during the install
phase. The wiki page mentioned before documents other variables available in
the install phase.
Some things I'm not clear on without trying it:
- how the touchpoint gets installed in the first place so that it can be run.
I'm assuming you have to prereq a bundle that includes this touchpoint and that
this touchpoint would install the normal way.
- how errors occurring in the native executable are communicated back to the
user. I'm assuming the native exe is a "black box" and that your
touchpoint action would have to invoke it and wait for its completion.
Also, here is a wiki page (somewhat stale) for gathering use cases for
touchpoints:
http://wiki.eclipse.org/Touchpoint_Use_Cases
Please report back on any attempts/progress in this area...
susan
"Farokh
Morshed" <fmorshed@xxxxxxxx>
|
|
"Farokh
Morshed" <fmorshed@xxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
08/04/2008 12:03
PM
Please respond to Equinox development mailing
list
|
To: "'Equinox development mailing
list'" <equinox-dev@xxxxxxxxxxx>
cc:
Subject: RE: [equinox-dev] Does Eclipse
support native installation scenarios?
|
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>
|
[IMAGE]
|
[IMAGE]
"Farokh Morshed"
<fmorshed@xxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
08/04/2008 09:04 AM
Please respond to Equinox development
mailing list
|
[IMAGE]
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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
#### image003.png has been removed from this
note on August 04, 2008 by Susan Franklin McCourt
#### image004.png has been removed from this
note on August 04, 2008 by Susan Franklin McCourt
#### image005.png has been removed from this
note on August 04, 2008 by Susan Franklin McCourt
