Community
Participate
Working Groups
There are use cases where feature will need to update or install additional IUs, but the user should not be bothered by any of the p2 things related. Thus a API for headless install/update and giving control over all related things (listed below) would be very valuable. Things one would want control over: * tell p2 specifically what to install ** either automatically try to install all required IUs as well ** or limit the installed IUs to a given list (have complete control over what this p2 install call will install) * hook into completion of an install ** e.g. HeadlessInstallListener for this (and other) event(s) * hook into progress indication (pass a monitor) * get control over Restart/Apply behavior ** most of the time the code that would install/update something, would also know wether apply is possible (and do it automatically) or a restart is necessary
I thank you for this expression of your requirements. In order to better understand the problems / need, I have added a few questions: (In reply to comment #0) > There are use cases where feature will need to update or install additional > IUs, but the user should not be bothered by any of the p2 things related. In this case do you refer to user as API user or end user? Could you give an example? > Thus a API for headless install/update and giving control over all related things > (listed below) would be very valuable. Is the current level of abstraction provided by IPlanner / IEngine sufficient or do you want something higher level, more like ProvisioningHelper that we have in the p2.console bundle? > Things one would want control over: > * tell p2 specifically what to install > ** either automatically try to install all required IUs as well > ** or limit the installed IUs to a given list (have complete control over what > this p2 install call will install) Could you details why you need this level of control? Is it to circumvent some other undesirable behavior of p2? > * hook into completion of an install > ** e.g. HeadlessInstallListener for this (and other) event(s) Is this to know when the installation is complete or failing? Today we have events on the p2 ProvisioningEventBus where we talk about completion of failure of install (e.g. CommitOperationEvent). Is this an acceptable direction? > * hook into progress indication (pass a monitor) We do accept progress indication in a lot of places, is there a particular area that you think need improvement, are we missing it in places? > * get control over Restart/Apply behavior > ** most of the time the code that would install/update something, would also > know wether apply is possible (and do it automatically) or a restart is > necessary Is that at the UI level? Or just in general providing ppl a return code that tell them what to do?
(In reply to comment #0) > There are use cases where feature will need to update or install additional > IUs, but the user should not be bothered by any of the p2 things related. Thus > a API for headless install/update and giving control over all related things > (listed below) would be very valuable. > > Things one would want control over: > * tell p2 specifically what to install > ** either automatically try to install all required IUs as well > ** or limit the installed IUs to a given list (have complete control over what > this p2 install call will install) > * hook into completion of an install > ** e.g. HeadlessInstallListener for this (and other) event(s) > * hook into progress indication (pass a monitor) > * get control over Restart/Apply behavior > ** most of the time the code that would install/update something, would also > know wether apply is possible (and do it automatically) or a restart is > necessary Please read bug 292996 comment 4. Much of what you are asking for is mentioned there. There's nothing inherently UI-oriented about the ideas there, as it's really just trafficking in ius, monitors, and statuses. The headless case simply means we don't go back to a user if something is wrong, but that the headless code figures out what to do next. I'd be interested to know if there's something you need that's not described there.
Susan, Pascal, thanks for the quick response. Indeed Susan you are right, what you are outlining on bug 292996 is what's needed for this bug here. Let's keep the discussion on bug 292996 (we will respond there soon) for now.
I just updated the "headless update" example (org.eclipse.equinox.p2.examples.rcp.prestartupdate) to use the new operations API instead of assembling updates by hand. FWIW, what was previously about 125 lines of p2 client code in P2Util is reduced to around 25 lines of code (and half of that is progress monitor management and exception handling.)
(In reply to comment #4) > I just updated the "headless update" example > (org.eclipse.equinox.p2.examples.rcp.prestartupdate) to use the new operations > API instead of assembling updates by hand. > > FWIW, what was previously about 125 lines of p2 client code in P2Util is > reduced to around 25 lines of code (and half of that is progress monitor > management and exception handling.) And actually, perhaps more interesting, is that after making this change, I was able to absorb a refactoring of the ProvisioningPlan class without changing any code. (ie, clients no longer even know what a plan is or what the engine does).
I'm going to mark this as fixed for my record keeping, as the work is done. Note we are responding to specific issues in new bugs. Of course it won't appear in an SDK build until the branch is merged back into HEAD. At that time I'll figure out what milestone to mark it, etc... The javadoc is up to date with examples and the branched example reflects the new state of the world. The branch is called R3_6_api_cleanup
changing milestone to M5. The p2 api branch will be merged back into HEAD early in M5
verified in I20100126-0100 via source inspection. If there are additional needs from the operations API, please open new bugs (note that M6 is API freeze.)
