Overview

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.

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.

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.1.

A new repo is created, with just one (the latest version), and is deployed. The uima website documentation indicates where to find older eclipse plugins (the Apache archive site, following the the naming conventions: uima/archive-eclipse-update-site/subsitename/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.

After this is done, the new subsite will 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.

Naming convention and locations

The archives are stored using this naming convention:

Root location:

uima/archive-eclipse-update-site/[particular-archive-name]

The particular-archive-name is named

subsite-name-x.x.x-y.y.y, where the x.x.x is the first version in the archive, and y.y.y is the last one.

Resetting the update site for a new batch of versions

Here is the procedure to reset the update site for a new batch of versions, going forward.

In the dist.apache.org svn for release, copy the to-be-reset update subsite to the new archive spot. Example:

svn copy -m "create eclipse plugin archive for uimaj-2.3.1-2.10.1" https://dist.apache.org/repos/dist/release/uima/eclipse-update-site/uimaj https://dist.apache.org/repos/dist/release/uima/archive-eclipse-update-site/uimaj-2.3.1-2.10.1

wait for this to appear on the archive site, e.g. https://archive.apache.org/dist/uima/archive-eclipse-update-site/uimaj-2.3.1-2.10.1

delete from the main site. Example:

svn delete -m "create eclipse plugin archive for uimaj-2.3.1-2.10.1 delete in main mirror" https://dist.apache.org/repos/dist/release/uima/archive-eclipse-update-site/uimaj-2.3.1-2.10.1

reset the main update subsite: best way is to delete it and then re-import it. Example:

svn delete -m "reset main Eclipse update subsite for uimaj - delete old one" https://dist.apache.org/repos/dist/release/uima/eclipse-update-site/uimaj

cd to import directory, eg. uimaj-eclipse-update-site/target/eclipse-update-site/uimaj svn import -m "reset main Eclipse update subsite" . https://dist.apache.org/repos/dist/release/uima/eclipse-update-site/uimaj