[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [p2-dev] RE: [equinox-dev] Does Eclipse supportnative installation scenarios?
|
Ciao @ll :)
Several months ago I submitted a patch that would disentangle
TouchPoints and their actions,
using that patch every provider of repos can specify their own actions
and the touchpoint will call them even if at the time the touchpoint was
created the action was not even defined anywhere.
HTH,
Ciao, hh
P.S.: bugzilla tracking this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203323
-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
Behalf Of Farokh Morshed
Sent: Wednesday, August 06, 2008 11:45 PM
To: 'P2 developer discussions'
Subject: RE: [p2-dev] RE: [equinox-dev] Does Eclipse supportnative
installation scenarios?
Thank you John for your clear and definite response.
We will continue to use the update manager and its install handler. We
actually have released a product using that technology and were looking
to switch over to using P2.
At this point, I would like to lodge a requirement to be considered for
P2 going forward: A new Touchpoint that provides a given string
representing a command line to the shell to launch a process immediately
after the payload is downloaded. Installation will wait until the
process launched exists.
Regards,
farokh
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
Behalf Of John Arthorne
Sent: Wednesday, August 06, 2008 5:09 PM
To: P2 developer discussions
Subject: Re: [p2-dev] RE: [equinox-dev] Does Eclipse support native
installation scenarios?
There are a number of limitations in the current release (3.4) that make
it a bit difficult to achieve the effect you are looking for if you want
it to run on 3.4.0. First, we don't yet support installing a new
touchpoint in the same install operation that wants to make use of the
touchpoint. If you have your own touchpoint that you want to install,
and then install something that makes use of the touchpoint, it would
have to be performed in two separate install operations (likely with a
restart in between). I.e., the sequence would look like this:
1) Install the bundle that defines your touchpoint, and any
prerequisites
2) Possibly restart depending on whether your bundles and the bundles
you interact with are dynamic
3) Now you can perform an install that uses your touchpoint.
I don't know if this is an acceptable situation for your product. This
is something we plan to support for the Gallileo (3.5) release (we refer
to this as sequenced installs).
Another issue is that the touchpoint code is currently provisional API.
This means it is not yet real API, and is almost guaranteed to change in
non-compatible ways in the 3.5 release. This could be an issue for you
if you want to support installation into both 3.4 and 3.5+ releases.
Again, we plan to convert this provisional API into real platform API in
the 3.5 release.
Finally, we lack good tooling support in 3.4 for authoring touchpoints
and touchpoint data. This is not a show-stopper, but means you may need
to write some code to generate any touchpoint data you might need (data
that is passed into the touchpoint action at install time).
I don't mean to discourage you, but want to give you a realistic idea of
the effort involved. What you are looking for is possible in 3.4, but we
hope to make much better and simpler in 3.5. A simpler alternative
available to you in 3.4 or earlier releases is to use update manager
install handlers, which you can read about in the Eclipse help. We
intend to deprecate install handlers over time in favor of the p2
touchpoint mechanism, but at least in the 3.4 release it may be a
simpler route.
John
"Farokh Morshed" <fmorshed@xxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx
08/05/2008 09:46 AM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
To
"'Equinox development mailing list'" <equinox-dev@xxxxxxxxxxx>,
<p2-dev@xxxxxxxxxxx>
cc
Subject
[p2-dev] RE: [equinox-dev] Does Eclipse support native installation
scenarios?
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
Inactive hide details for "Farokh Morshed" <fmorshed@xxxxxxxx>"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
<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
<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
<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
<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<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 _______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
