Page History

...

Due to an error in setting this up initially, there is also a directory .../incubator/uima/eclipseUpdateSite . The next release will put things on the eclipse-update-site directory, and remove the temporary .htaccess file that is redirecting which was used for the 2.2.1 release. As of the 2.2.2 release, the update site is now the eclipse-update-site to eclipseUpdateSitedirectory.

The build process packs and compresses the plugin jars, and builds a packed/compressed form of the website, using Eclipse tooling to do this.

The update site support consists of 2 several feature projects and one update site project. There is a feature project per separately installable feature. The base UIMA has 2 features are there because one . One feature is for users who might wish to integrate UIMA into an RCP - it consists of the "runtime" part of UIMA, without the Eclipse tooling plugins for UIMA. The other feature are the Eclipse tooling plugins for UIMA. The 2nd feature has the first one as a prerequisite, and also prereqs EMF.

The update site "build" is done by an ant script called by maven's ant-run plugin, but the script (in the uimaj-eclipse-update-site project, called build.xml, and located in the eclipse-update-site project) can also be run directly (for testing). Before running it, change the property values in the top (read the script) to reflect the version you are building.

Each time we go to a new version, we (currently) keep all things version-synchronized. The 3 projects have version information in them that is udpated.

The Eclipse eclipse-update-site (in apache.org/dist/incubator/uima) holds many versions. (The number is up to us - but for now, it will hold all the versions). The HEAD of the SVN always has the current version. When a new version is created, the version numbers in the project are incremented, and the site.xml in the eclipse-update-site project is augmented to add the new versions of the plugin.Currently, the strategy is to do a new version with every uima release, so everything is kept in syncThis allows users of the Eclipse update process to select an older version, if they desire.

Old versions that were previously put up as part of the update site, are kept available. There are 3 kinds of information that are kept for older versions:

1. the site.xml - holds references to previous versions
2. the jars built for the features
3. the jars for the associated plugins
   The previous plug-in jars are kept on apache.org/dist/incubator/uima; the jars for previous features are kept in SVN.

Update site build process

The version numbers are incremented in the 2 new feature projects and the site project, and new site entries are added for the new version. The build process will create the update site in the /target of the eclipse-update-site project; this will be complete except for the jars of the previous version of the update site. The "upload" for this will therefore need to merge these files with the existing files in the update site.

Tagging the site build

Each time the update site is augmented with a new version, the affected/changed files should be tagged in SVN. The update-site build is associated with a new approved & tagged release candidate. Add a tag that has the same name as the release candidate it goes with, augmented by -eclipse-update-site. This will preserve the state of SVN that was used for building the Eclipse update site.