[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] approaches to Install Handlers

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
2) create the requiredcapability to do a query
3) have providedcapability action metadata available for those IUs.

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


Inactive hide details for Henrik Lindberg ---01/02/2009 11:31:13 PM---Hi Pascal, Your feedback arrived with perfect timing :)Henrik Lindberg ---01/02/2009 11:31:13 PM---Hi Pascal, Your feedback arrived with perfect timing :)


From:

Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx>

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Cc:

p2-dev-bounces@xxxxxxxxxxx

Date:

01/02/2009 11:31 PM

Subject:

Re: [p2-dev] approaches to Install Handlers




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:
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. 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. ok. 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).
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). 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? I was not assuming any particular complexity. Again, if the install handler is always installed into the provisioned system this problem goes away. 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...
I am only using GUi as an example that pushes the limits of what can be done with a particular solution. 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).
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


GIF image

GIF image