UIMA project logo
Archiving Eclipse Plugins
Apache UIMA

Search the site


The Eclipse Update Site holds a multi-update-site root, which, in turn, links to various subsites (for various projects). Each of those subsites typically has several versions of the plugins; a release process adds fresh versions of plugins to that site.

At some point, there are too many versions, and it makes sense to archive these older ones. To do this you need to run Eclipse special tooling to keep the artifacts.jar and content.jar artifacts in sync with the features and plugins.

 Goals for archiving

An archive approach would, ideally, have these properties

  • Reduce the number of choices during the Eclipse install menus to just the more recent ones
  • Support an older "archive" site where older version could be obtained if needed, without loading the Apache Mirror system.
  • Have a simple mechanism for archiving older releases

 Strategy for archiving

The basic strategy is to have multiple update sites:

  • A more-or-less current one, which has the most recent plugins, plus perhaps a few of the older releases
  • Older plugin site(s) (not too many) which contain ranges of plugins

A typical imagined timeline would be

  • A subsite is started (e.g. ruta, or uimaj)
  • Releases occur, and plugins are added at some version level
  • After some number of releases, a decision is made that the repo is getting too big. At that point, a small number (default, just the most recent) version is sliced off into another repo.
  • The old repo is renamed with a suffix indicating the range of versions in it. For example, the "uimaj" repo might have a name uimaj-2.3.1-2.10.0.
  • The new slice repo, with perhaps just one (the latest version) is then deployed. A one-time update to the site documentation is made to indicate where to find older eclipse plugins (the Apache archive site, following the the naming conventions: uima/eclipse-update-site/---subsitename-x.x.x-y.y.y).
  • After confirming that the renamed old site is visible in Archive, then it is deleted on the main release site.

A typical new slice would have just the latest version in it, and would then be added to over time, with additional releases. When it gets too big, the same procedure is repeated, with a new named update site .../---subsitename.u.u.u-v.v.v with another range set being created and archived.

 Doing the slicing and updating the site

The eclipse ant tasks for maintaining update sites are documented here: https://help.eclipse.org/oxygen/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_repositorytasks.htm .

This ant task is used in a Maven project, located in uima/build, named: uima-eclipse-update-site-slicing. This does the slicing described above. To use, check out this project as a maven project (it's not a Java project), and read the readme.txt, and follow the instructions.

When it runs, it reads the existing subsite directly from the dist.apache.org repository, and builds the request slice in the project's target/eclipse-update-site/---subsite--- directory.

To complete the maintenance, do these steps in the dist.apache.org svn release eclipse-update-site:

  1. Do a sanity test of the new subsite - try installing it into a fresh Eclipse install.
  2. svn mv to rename the current subsite to the versioned name.
  3. once it appears on the archive spot, do an svn delete to remove it
  4. import the new (pruned) subsite to the release spot.