Solution for building an offline “composite” Eclipse update site with categories

Question

This is going to be a pretty long question, so bear with me. I'm looking for a solution to build custom update sites (or p2 repositories) for use in an offline development environment, with the following things in mind:

• Each site will contain a mix of 3rd-party and custom Eclipse plugins.

• I'd like to create a single site per IDE configuration. e.g. Developers using Helios only need to add 1 update site containing m2e, Subversive, and CustomPluginA. Developers using Flash Builder can add a different site containing m2e and CustomPluginB.

• Since development is offline, we currently mirror 3rd-party update sites with a script. The custom sites need to draw plugins from these copies.

• Our custom Eclipse plugins are currently built with Maven + Tycho on Jenkins. If possible, I'd like to configure the update sites to build automatically with Jenkins as well. Then, if a custom plugin is updated, it can trigger the necessary update site builds.

• Custom categories in the update sites would be nice.

I'm trying to find the best and cleanest way to approach this. How can I set something like this up using Tycho to build the sites? Is Tycho even the best option? Do I want the 3rd-party plugins to be copied to each site, or do I want to create p2 composite repositories which point to each of the mirrored 3rd-party sites. Is it possible to create custom categories with a p2 composite repository?

And finally, what is the easiest way to actually define which plugins and features are included in a site? In Eclipse I can create an Update Site Project which makes editing very easy, but I can only include plugins which exist in that Eclipse installation. Creating a site.xml or p2 ant script by hand solves this problem, but determining installable unit IDs and versions by hand is difficult and error-prone.

Thanks for taking the time to read all this. If anyone can actually address all of my concerns that would be amazing and I'd probably have to add a bounty to this question.

Answer 1

I will suggest two ways, one with Tycho and one with the B3 aggregator.

1) Tycho:

Step 1.: Define a target platform using PDE built-in tools, that uses your existing local update sites, and save it as a .target file. Then you can reference this file in your build like the following:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>target-platform-configuration</artifactId>
  <version>${tycho.version}</version> <configuration>
  <resolver>p2</resolver>
   <target>
     <artifact>
      <groupId>org.eclipse.viatra2</groupId>
      <artifactId>«project name where the target file resides»</artifactId>
      <version>«artifact version»</version>
      <classifier>«target filename without extension»</classifier>
     </artifact>
   </target>
   <ignoreTychoRepositories>true</ignoreTychoRepositories>
  </configuration>
 </plugin>

Step 2.: Define a new project as an update site. The project should contain a category.xml referring the used versions of the used features of the target platform from the previous step. You can create this category.xml using the PDE Category definition wizard/editor.

Step 3.: Simply publish your build using the update site archetype:

<packaging>eclipse-repository</packaging>
<build>
  <plugins>
    <plugin>
      <groupId>org.eclipse.tycho</groupId>
      <artifactId>tycho-p2-publisher-plugin</artifactId>
      <version>${tycho.version}</version>
      <configuration>
        <publishArtifacts>true</publishArtifacts>
      </configuration>
    </plugin>
  </plugins>
</build>

2) B3 Aggregator:

The Eclipse B3 project contains an aggregator feature. Using the Aggregator you define a model which uses existing update sites, then simply execute this model using the Aggregator, and the result is an update site. In the latter case you can either build a composite update site, that refers to other update sites, or you can create a standalone copy from the original data. The manual contains a simple example, it is easy to use.

3) Comparison

Defining the mirroring logic is more straightforward in B3, as the model contains only the mirroring description, and also allows the creation of composite update sites that only reference the existing sites. However, if you want to do anything else besides update site building, then it is harder to do. Additionally, it can be executed in headless builds (e.g. from Jenkins), but it needs an installation of a headless Eclipse instance. The documentation contains the details, but the tool is not standalone like in case of Maven/Tycho.

In case of Tycho it is harder to see the structure of the resulting update site, however, the resulting build is more extensible (e.g. you can simply add your own features using the same kind of build), and to do a build you only need Maven installed.

So alltogether, both tools might fit your needs - you need to evaluate their strengths and weaknesses in you case.