Reuse existing bundle pools

[laeubi]

Currently PDE maintains its own bundle pool in the workspace, this has many drawbacks:

1. Multiple workspace download the same things twice
2. Oomph has its own bundle pool and download things as well
3. Tycho also

PDE should have some mean to access existing well known pools of P2 items to leverage already downloaded content. As we have hashes + signatures if in doubt one could even verify that data from such pools is "true"...

[merks]

Note that I've verified manually, by instrumenting org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRequest.setSourceRepository(IArtifactRepository), that this very simple change will ensure that any artifact already available in the pool will be fetched in favor of the remote artifact. So I see what comes from the pool:

file:///D:/Users/test32/.p2/pool/->osgi.bundle,bcpg,1.76.0

versus what comes from the remote site:

https://download.eclipse.org/eclipse/updates/4.29/R-4.29-202309031000->osgi.bundle,bcpg.source,1.76.0

[HannesWell]

Note that I've verified manually, by instrumenting org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRequest.setSourceRepository(IArtifactRepository), that this very simple change will ensure that any artifact already available in the pool will be fetched in favor of the remote artifact. So I see what comes from the pool:

You are referring to #878, don't you?
So this does not add new artifacts to the shared bundle pool if they are not yet present and only required by PDE?
For that the profile of the target probably would have to be registered in the shared bundle-pool, wouldn't it?

[merks]

Indeed, the shared bundle pool is managed by a shared agent that manages all the profiles, i.e., of all the installer-installed installation profiles and all targlet profiles. Without such proper management, a pool would just grow indefinitely and could never be garbage collected. The shared agent itself is implemented by and managed by a large stack of technology where the bundle pool is just the tip of a vast iceberg.

[HannesWell]

The shared agent itself is implemented by and managed by a large stack of technology where the bundle pool is just the tip of a vast iceberg.

Is that technology-stack part of P2 or Oomph?
If it is not yet part of P2, it might be worth to migrate it there as part of eclipse-equinox/p2#373?

[merks]

Here is what we are talking about "migrating":

It's a daunting task, with no associated funding. I'm not even convinced it's entirely sensible. Perhaps it's similar to asking m2e to migrate some parts to PDE. So far the approach there has been for m2e to provide extensions for PDE, not migrating into PDE...

Perhaps PDE could provide some service, with a default implementation, that Oomph could extend to "inject" a shared agent with a shared bundle pool. I just don't know my resources are limited...

[laeubi]

Perhaps it's similar to asking m2e to migrate some parts to PDE

In fact everything not maven specific is already migrated to PDE, espcially m2e was a driver for Target Editor enhancements, so in general I think its good to have as much as possible in P2 (!) rather than PDE so it can be used at Oomph/PDE/Tycho/... but lets start with reading that pools :-)

I think Tycho (FYI @opcoach ) would be another "pool" that is suitable to be integrated here I have created

• Write a artifact repository for the local metadata and any cached items eclipse-tycho/tycho#2995

for that purpose.