P2 Repository FAQ

Can I mirror a remote P2 repository for use in Nexus behind a firewall?

If you need an offline copy of a P2 repository, see the Eclipse P2 mirroring instructions.

When looking at an external site, how do we know if it’s the new “P2” style or the old “P2 Update Site” style?

If you can see the site's directory listing then you easily tell. "p2" sites will have metadata files like this at the root (these might be "jar" or "xml" files):

  • content.xml/content.jar
  • artifacts.xml/artifacts.jar
  • compositeContent.xml/compositeContent.jar
  • compositeArtifacts.xml/compositeArtifacts.jar

"p2 Update Site" repositories will only have this:

  • site.xml

Sometimes sites publish both types of metadata. In this case you should use a "p2" proxy repository.

If you can't see the directory listing try adding the proxy as type "p2". If this works then you will see "content.xml" and "artifacts.xml" files in the root of the proxy' repository's local storage. If it does not work try adding the site as a "p2 update site" proxy.

Can the old style and new style p2 proxy repositories work inside one group?


Our current groups are set to “p2 Deprecated”, do we need to change them?

The new style p2 group repositories in Nexus use composite p2 metadata, consequentially they are far more efficient than the old ones. However, the new style groups are only compatible with Eclipse 3.5 and higher. So if you are using Eclipse 3.4 stick with the deprecated groups, otherwise change to use the new ones.

Are there any scheduled tasks which need to be run on a regular basis for p2 repositories?

It is not necessary to run any scheduled tasks for "p2" proxy repositories, these obey the "metadata max age" setting in the proxy. Updates to the remote's p2 metadata files will be detected whenever this timeout expires. The default is every 24 hours.

For old style "p2 update site" proxy repositories you need to schedule the "Mirror Eclipse Update Site" task to run periodically.  For these, Nexus needs to periodically download all of the feature and plugin jars from the remote, and then locally generate p2 metadata files by scanning them. As you can imagine, this is an inefficient process. This is why it is preferable to use p2 style proxy repositories if possible.

Have more questions? Submit a request


Article is closed for comments.