Supply a general entry point for accessing P2 pools

[laeubi]

There is some demands to share already downloaded data when accessing updatesites and different tools have different locations/caches to store items (see eclipse-pde/eclipse.pde#875, eclipse-tycho/tycho#2990).

We should define a general entry point for such tools to discover, read and add such pools with a global registry.

It could start as simple as P2Pool.getPools() returning a Stream of IArtifactRepositorys that list all known to the registry.
Later on we might want P2Pool.addPool(Path) to add one permanently and P2Pool.addPool(IArtifactRepository) to add one transitively for the current run of the virtual machine.

[mmosconi1]

It seems that ~/.p2/pools.info is regarded as fixed/global reference for bundle pools. But this is only true if ~/.p2 is set as Agent location!

When I change to a different Agent (and Bundle Pool) via Oomph "Bundle Pool Management", ~/.p2/pools.info

• is empty, if I removed the original Agent
• contains only the old bundle pool, if I didn't remove the old Agent

Oomph itself seems to get its information from agents.info / defaults.info below ~/.eclipse/org.eclipse.oomph.p2.
Maybe this or some other place under ~/.eclipse is better suited to host the "global" pools index?

Background: in our company (using Windows mainly), installation files and/or caches should not be stored under the user home directory. For that reason, we define a different Agent/Pool location.

[merks]

Indeed. I mentioned in one of the commits that the agent manager is more general and supports multiple agents each of which can define pools. Longer term we can support that too, which is why I did not close this issue. But that’s like 1 in 1000 users, or fewer.

Is your company contributing to Eclipse? 😁

[mmosconi1]

But that’s like 1 in 1000 users, or fewer.

I could imagine that many companies don't want/allow such things goings to user directories (e.g. think about "roaming profiles" or shared desktops or virus scanner exclusions).
Just be aware that (technically) ~/.p2/pools.info is not a safe anchor. Maybe we need sth. similar as for Maven local repositories, where I can override the default location (~/.m2/repository) via ~/.m2/settings.xml or -Dmaven.repo.local.

When thinking about support for Agents: if someone goes for different Agents to separate scopes for some reason*, I think PDE or Tycho should not use a "flattened" list of bundle pools across Agents, but only those of the "active" Agent. For PDE this seems clear (the Agent used in this workspace or Target Platform), for Tycho I have no idea how to define such "active" Agent. In the Installer, I have to select exactly one bundle pool already.

(*) e.g. regarding security level ("certified" from trusted sources vs. "wild")

[laeubi]

@mmosconi1 We are doing small steps here that work for a larger audience of users with default setups. This will likely be enhanced/improved and the good thing is that the API facade we offer here should hide all the details and that's the key here.

If you have special demands, feel free to help with this and start a contribution, it would be great to enhance the idea to even more functionality Ooomph offers.

Regarding agents I think the best would be to define a IPoolService and acquire this from the IProvisionAgent this can the handle any agent specific locations or behavior, once this is there we can migrate code to use that service as well.

[merks]

@mmosconi1

I have moved the encoding.info to the folder of the agents.info and I have updated the p2 helper to read the agents.info to locate all the pools. If someone doesn't want this behavior, it can be turned off via -Dpde.usePoolsInfo=false. And of course if folks don't want things written into their real user home they can use -Duser.home=<somewhere-else>, which I use all the time for testing things without risk messing up by real user home.

Note that PDE was already doing all kinds of questionable things such as loading all artifacts repositories from the Install/Update preferences. The whole point of much of that stuff is that one might as well use a local artifact already on disk rather than download it again from the internet...