[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