Thanks for the info. It sounds like a cool feature and I was curious about its maturity, I don’t have any particular use case in mind.
The information where to store each bundle is a though one. Surely the engine is no fortuneteller so this data has to be encoded in the repository or passed. Figuring out the default behavior when dealing with old p2 repositories sounds tricky.
For the sake of speculation I guess it there are two ways to make this work:
- the repo would be updated to define a target pool for each artifact, the pool would be created if needed on the target system. In case no data is provided for some(all) of the IUs with artifacts – put them in plugins (the default pool).
- why not pass the pool data when installing an IU? - Here the tricky part is to decide whether the passed pool applies only to the installed IU or to its dependencies as well. The first approach seems more consistent…
In a nutshell much stuff to figure out and probably not enough use-cases(but still high degree of coolness :) ), no wonder this feature is a bit on hold.
Best Regards,
Borislav
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: Monday, November 28, 2011 5:15 AM
To: P2 developer discussions
Subject: Re: [p2-dev] multiple bundle pools
The ability to explicitly deal with multiple bundle pool through a regular provisioning operation is not implemented - which is why this bug is still open.
At this point p2 deal with one bundlepool which can be located anywhere and shared by multiple installs. By default the eclipse install folder is a bundle pool and it is the only case where roaming is supported.
The mechanism that backs p2.cache.extensions property only supports read only repos (a bundle pool is another name for a local repository). This code has been added to support the case of the dropins and other legacy setups of extension locations where it was possible to store plugins in random folders by unzipping them in place.
For p2 to write into different pools, the existing code would have to be changed, or a new type of repository allowing for this kind of thing to happen would be added. For example you could imagine having a new type of repo that would know how to write to specific sub repos and know how to route the bundles into the appropriate place.
Now to step back a bit, what are you trying to achieve?
Where would you expect the information on where to store the bundle to come from?
On 2011-11-24, at 9:37 AM, Kapukaranov, Borislav wrote:
While that’s quite exciting I couldn’t find a way or guide how to use it during provisioning.
The director’s “-bundlepool” argument is respected only at profile creation as the documentation suggests.
Also I was curious how this behaves with roaming profiles. On one hand the bug hints this could be used in Eclipse(a roaming installation), but on the other the “-roaming” documentation says that this argument only makes sense when the pool and the destination locations match.
I see I can specify the “org.eclipse.equinox.p2.cache.extensions“ during initial provisioning of a product, using the profileProperties.
So far so good, but on subsequent provisioning operations on this profile how do I specify in which pool I want my plugins to go?
