[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[p2-dev] approaches to Install Handlers
|
Hi,
I have looked into the issues of supporting "install handler like
functionality" in p2. And I am trying an approach to provision the
"install handlers" using p2 (as opposed to doing something similar to
the current install handler functionality with a specially packaged
jar). Before continuing the work - I wonder if you considered using
(full) javascript to describe installation actions? One idea could be
to use org.mozilla.javascript 1.6.6 which is in Orbit (size is 615 kB).
An IU could contain the full definition of the actions required. As
long as you have the IU you will never lose the definitions. It is
simply a matter of providing access to an appropriate set of objects
from java script.
Don't know if you considered this and rejected the idea?
When comparing a javascript solution with an p2 based alternative -
one needs to consider these things:
- If a plan is created that requires operations on IU's that have
"install handlers" - these needs to be provisioned into the running
agent environment
- If the running agent environment is the same as the target
environment, the original plan may be wrong and needs to be redone
once the install of the "install handlers" have been performed.
- Different agents may over time operate on the installed target -
they all need to have the "install handlers" installed - to do this
they must find them somewhere
- If the agents are to get them from remote repositories - it may be
impossible to uninstall an IU if the "install handler" is no longer
present in any repository
- If an agent is written with a different technology than the original
agent, the "install handler" must be resolved against a repository
where all its required capabilities are found - this may be remote -
and again, may have been removed - thus making it impossible to
uninstall an IU.
- Once an agent has used an "install handler" it should probably get
rid of it to avoid bloat in the agent profile, and to avoid potential
problems later when the same agent needs to install something that
conflicts with a previous install operation.
The solution for "missing bundles" would be to start by mirroring them
into a special local repository only holding what is required for
install handlers (Thereby securing that they at least are available
locally). If p2 "applications" use profiles in one known location the
install handlers could be installed there as that would solve a
problem of having install handlers that have dependencies on platform
and UI. Currently, I don't think that is the case (i.e. installer
etc. are not downloaded into some shared location). A worst case would
be where user first downloads the installer, then wants to install
something that requires install handlers with bundles that require UI.
User then installs the thing they want to install, and p2 yet again
downloads the same bundles that were installed first for the
installer, and then for the install handlers).
This is still quite kludgy, and still breaks if two different users
run their own setups, and a super user tries to help another user with
provisioning actions - the super user would need to also get the
"install handlers" into the agent instances used by the super user. (I
am sure there are other problem scenarios as well).
I think solutions is a bit too loosely coupled for my taste.
A Javascript solution would naturally not be as powerful - it would
not be possible to write a complete GUI for instance (unless someone
provides the needed glue), but I think that can be worked around quite
easily.
- Authors of IUs that require install handlers always (as they do
today) have the option to write custom installers (with their own
touch points, actions, etc.). These installers can have advanced GUI,
Wizards etc. The problem is that the user would need to first download
their installer and run it.
- A IU with javascript could easily have instructions that provisions
and executes a second custom p2 based installer (or any other type of
installer for that matter).
- To reduce the need to write custom installers the javascript could
be given access to a simple API that allows some basic user
interaction (ask a question, show a message, etc.) as this can easily
be provided in both a headless and a GUI version.
A related idea is to provide a two phased approach where the first
install bequests a second provisioning run when the target starts.
There are situations where this is the preferred approach. Say I want
to checkout projects in a workspace and get them built. In order to do
so from any p2 installer, the installer would need to get a *lot* of
bundles - practically turning it into a full IDE (when the initial
download is done by a browser the user does not benefit from parallell
downloads, compression optimization etc). If p2 instead could bequest
a provisioning operation on startup of the target the initial
installer can stay small. The bequest mechanism could then naturally
be used when custom install handlers in java are required.
So - which of the ideas do you think are worth exploring?
- The p2 (only) based approach
- Using a jar file like the update manager's install handler (it has
its own set of issues that I did not describe above).
- Using java script
- Using bequests
Regards
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
