[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] approaches to Install Handlers
|
re:Do you mean the "action capability"?
Yes. Here's a quick description of what I'd like to try.
When engine.validate is called in a situation where we don't have all the necessary actions installed a MissingActionException will be thrown that can be introspected for the missing action ids and version ranges.
Using this info I'll create the RequiredCapabilities for the actions and place them in a dummy IU. I'll then add this IU to the "self" profile and then use the planner to get something I can use with Engine.perform to add the new actions to the install.
After this has completed successfully I'll go back and re-plan the original request and hopefully perform it.
What I'm trying to do is obviously a green thread. (e.g. works but maybe not pretty ... yet)
The workflow probably need work as well as many of the implementation details however at this point I'd really like to see something that at least sort of works before getting more fancy.
-Simon
![Inactive hide details for Henrik Lindberg ---01/14/2009 07:09:18 PM---Hi Simon, you can add me directly with a CC in bugzilla o]()
Henrik Lindberg ---01/14/2009 07:09:18 PM---Hi Simon, you can add me directly with a CC in bugzilla on issues you think are of interest in this area if you like. 2) create
![]()
From: | ![]()
Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx> |
![]()
To: | ![]()
P2 developer discussions <p2-dev@xxxxxxxxxxx> |
![]()
Date: | ![]()
01/14/2009 07:09 PM |
![]()
Subject: | ![]()
Re: [p2-dev] approaches to Install Handlers |
Hi Simon, you can add me directly with a CC in bugzilla on issues you think are of interest in this area if you like.
2) create the requiredcapability to do a query
3) have providedcapability action metadata available for those IUs.
Do you mean the "action capability"?
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
On Jan 14, 2009, at 11:12 PM, Simon Kaegi wrote:
Hi Henrik,
I've started to work on and think about the various building blocks we might need to:
1) determine what actions we need in order for an install to proceed
I did some work in https://bugs.eclipse.org/bugs/show_bug.cgi?id=252694 that should do step 1.
I'm working on the other steps now (step 3 currently) but I'm hoping to do something fairly quickly so we can try out some workflows.
As I open bugs in this area I'll CC you -- hopefully tou won't mind :p
-Simon
<graycol.gif>Henrik Lindberg ---01/02/2009 11:31:13 PM---Hi Pascal, Your feedback arrived with perfect timing :)
Hi Pascal,
Your feedback arrived with perfect timing :)
I just finished writing unit tests for the implementation of Version and Version range that we proposed, and planned to look into "install handlers" again.
Comments inline...
Regards
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
On Jan 2, 2009, at 10:17 PM, Pascal Rapicault wrote:
Hi Henrik,
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).
After I wrote the email, I came to the conclusion that always installing the "installer handler" into the provisioned system is a way to handle the cases I had concerns about.
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
> from _javascript_.
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.
Note that, in the early days of p2 we had a prototype using _javascript_ as the action language instead of our "DSL". Java objects were being exposed through _javascript_ and ppl could use those. We backed out of it because the "power" of _javascript_ scared ppl and also because the objects exposed to _javascript_ became de-facto API which we saw as a potential problem to allow for API evolution.
ok. FWIW... I think people should be just as afraid of getting java code, and that the JS API's would be just as provisional as the other p2 APIs.
Always installing the "install handler" in the provisioned system solves the problem of the "install handler" not being available at a later stage. (My point was . that if the installer handler was indeed expressed in the IU that needs it (i.e. written in _javascript_ in the meta data)) it would always be in the provisioned system.
> 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
Correct. The idea you emitted about having meta-dependencies to an IU was the path we were on as well.
ok.
> - 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.
If "install handler" is always installed in the provisioned system dual planning is not required (although in the case of an external agent, a plan must be created for it).
> - 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.
Again, if the installhandler bundles are always installed in the profiles where they are needed - this never becomes a problem. Only issue is that an external agent needs to find them (and be able to use them).
> - 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.
I don't quite understand - are you saying that an external agent would simply use the install handler bundles (and their dependencies) in memory, or are you suggesting they are installed into some temporary profile for 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).
I was not assuming any particular complexity. Again, if the install handler is always installed into the provisioned system this problem goes away.
> 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.
How would those install handlers find their way in the agent?
If someone create their own installer with touchpoints and/or actions and package that up as the installer for their app (and naturally also including the same touchpoints and actions in the application (if it can manage itself)). But - that is what we are trying to avoid by allowing the install handlers to be defined dynamically...
> - 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).
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.
> - 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.
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...
I am only using GUi as an example that pushes the limits of what can be done with a particular solution.
> 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.
Bequests to the installed profile would probably be too late in that case - the reason to have something like a registry key would probably be to configure things to make the system start at all - and hence, the the user would never be able to invoke the profile that has the bequests. If a bequest was the only mechanism, the first p2 agent would install the registry key action into a second (temporary) p2 agent profile, and then bequest the rest of the installation into this profile - it would then execute the just created profile.
If the agent is running in the Eclipse IDE, it would not be fun restarting the IDE. So, if bequests was the only mechanism, it would be better to fork an external agent (i.e. the same as in the external agent case).
> 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 _javascript_
> - 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.
I agree with you. I think a combination of "simplest possible solution" for the main scenario for 3.5 in combination with a bequest mechanism for more complex cases makes most sense. If it is possible to require that "install handler is always installed into the provisioned profile" I think it will be much easier. I will start to dig into the details of such a solution right away.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
