|Re: [p2-dev] approaches to Install Handlers|
Despite the potential problem of "polluting" the provisioned system and the complexity it brings to the resolution and installation, the current thinking was to do something where the install handlers were also being installed in the provisioned system. This allowed for both simple actions and full touchpoint to be installed and offered a consistent model to contribute actions to an external agent or to an "embedded" one (the case where p2 is running and provisioning the provisioned system).
Though I understand your worries and you raised valid concerns to be careful about, I would like to understand why you are more worried about installing extensions to p2 when it is being run "embedded" than you are of having p2 run like it does today (in the SDK the agent is "embedded")?
> 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
I'm not sure I follow, but the basic problem that we are trying to resolve with "install handlers" is one where what is needed to do the installation is not provided by what is coming out of the box with p2. For example, today, if someone needs to add a registry key, p2 does not provide an action. Consequently some additional java code and native code needs to be downloaded and installed.
> 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
Correct. The idea you emitted about having meta-dependencies to an IU was the path we were on as well.
> - 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.
Yes, dual planning needs to be done, unless we can take the meta-dependencies into account earlier.
If no solution can be found, it may be required for the provisioning operation to be executed by an "external" agent.
> - 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.
It should be possible to keep the install handler bundles and their metadata around in a cache that could be consulted by other agents.
> - 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.
This is a fine question. In the case of an "embedded" agent, one could think that the handlers should stick around since they will be needed sooner or later. Also there is already install handlers in the installations (e.g. install bundle actions, set VM arg, etc) and they don't bother anyone.
On the "external" mode I think this is not necessarily relevant since I think those install handlers are never installed strictly into the agent profile. They are installed as a consequence of what the user is trying to install in another profile and as such they are installed optionally in the agent.
> 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 where it would be beneficial to promote bundle pooling.
You seem to assume that people are writing super complex actions providing completely new user interfaces, and I think this is were the main discrepancy is at least in the problem we are trying to solve for 3.5. We are not trying to provide users the ability to change the installation experience in profound ways (e.g. we don't want ppl to change the p2 screens or turn the default p2 UI into a installer), we simply want to provide the actions that are missing (e.g. add a window registry key).
> 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
> - 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.
How would those install handlers find their way in the agent?
> and executes a second custom p2 based installer (or any other type of
> installer for that matter).
This should still be possible with the approach we are talking about. It suffices to have an action that forks a new instance of p2.
> 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.
You seem to put a lot of emphasis around GUIs and I fail to see why. Note that initially (3.4) we wanted to create a UI service where IUs or actions could query for user input (http://bugs.eclipse.org/206903), however the lack of concrete use-case and time scoped down this work to only provide a facility to show certificates (see IServiceUI). Ideally this whole mechanism would allow for identifiers to be associated with what is being asked to the user, would have some metadata about the type of information being asked (see Metadata type service in OSGi) and would also allow for the default UI to be replaced... but this is only ideally...
> 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.
This is an interesting idea, at one point we had discussed the idea of being able to queue up "profile change requests" and having them persisted such that if an operation requested a restart, it could be continued once the application is up again. That said, I'm not sure how this bequest mechanism helps addressing the scenario of someone installing software that needs to for example add a registry key.
> 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 bequests
I really appreciated the thoughts you put into this and you touched on things that we will have to look into. Right now I'm still for exploring the p2 based approach for the reasons I evoked earlier and also because I'm really trying to only have one mechanism for people to provide actions. Having several would result in confusion and if we were to come up with something alternative to the action model to solve the dynamic install problem, we would weaken the action model since most people would use the dynamic model because the main thing they care about is to have their bit of code (to chmod, add registry key, etc) run when their feature is installed and without having the user notice.
That said I would still want to understand better the two other proposals you had to be sure to not miss out on things.