RCP Best Practices – Mirror Eclipse repositories

Getting started

  1. Introduction
  2. Know where to get help
  3. Use RCP for the right reasons
  4. Use the correct version of RCP
  5. Use the correct tools
  6. Set up a target platform
  7. Mirror Eclipse repositories
  8. Create a product configuration
  9. Define products with feature based dependencies
  10. Remove versions from product dependencies
  11. Always run code using a product configuration
  12. Get your product building right away

When setting up a target platform, it’s a good idea to insulate yourself from dependencies on outside servers. Many organizations currently create internal Maven repositories to perform this same role. For Eclipse RCP development, this insulation takes the form of partial mirrors of p2 repositories hosted at the Eclipse Foundation and perhaps elsewhere.

Creating a mirror

Creating a mirror is fairly straightforward. There is a p2 Ant task that can be used to create the mirror (a complete list of p2 Ant tasks can be found here). These Ant tasks are special in that they need to be run via the Eclipse antRunner application. This means that you’ll need a full installation of Eclipse on the machine that will run the task.

So here is a simple Ant script that will mirror the Eclipse 3.8 Platform SDK.

<project name="Create Mirror" default="create-mirror" basedir=".">

	<property name="target.dir" value="/path/to/my/mirror/repo"/>

	<target name="create-mirror">
		<p2.mirror source="http://download.eclipse.org/eclipse/updates/3.8" destination="${target.dir}">
			<iu id="org.eclipse.platform.sdk" />
			<iu id="org.eclipse.pde.junit.runtime.addon.feature.group" />
		</p2.mirror>
	</target>
</project>

When your Ant task is ready to execute in a build.xml file, you can use a batch file or shell script to execute. A shell script would look something like this.

/path/to/my/eclipse -noSplash -application org.eclipse.ant.core.antRunner -buildfile /path/to/my/build.xml

Mirroring tips

My first suggestion is to mirror only what you need to. You don’t need to mirror an entire Eclipse repository just in case you need something. Think hard about what your dependencies are and mirror those. Also, if you create a target definition that works with an Eclipse repository, you can view that file in an XML editor to find out what ids to use in the mirror task.

I also prefer to mirror different frameworks to separate local p2 repositories. So if you need EMF, GEF and the Eclipse Platform, I would create three separate mirrored p2 repositories. I find that this makes the mirrors easier to manage. If you’d prefer to see all of your mirrors as a single internal p2 repository, composite p2 repositories make this very easy to do.