To run the build for any of the Eclipse update sites, you must have
maven property variables set to identify an accessible Eclipse
installation (4.2 or later) so the Eclipse packaging tooling and Ant support
can be located. These are typically put into your .m2 setttings.xml
file like this:
<uima-maven-build-eclipse-home>C:/x/y/z/eclipse</uima-maven-build-eclipse-home>
<eclipse-equinox-launcher>
${uima-maven-build-eclipse-home}/plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
</eclipse-equinox-launcher>
<uima-eclipse-jar-processor>
${uima-maven-build-eclipse-home}/plugins/org.eclipse.equinox.p2.jarprocessor_1.0.200.v20110808-1657.jar
</uima-eclipse-jar-processor>
The first decision when doing an update is to decide if
you need to add a new sub-update-site to the set managed by the
Composite collection. If so, update buildCompositeRepository.xml
in the build/trunk/uima-eclipse-composite-update-site
to add the sub-site.
To update a sub-site, go to that subsite's project for its update-site.
For example, for uimaj, this is the project uimaj-eclipse-update-site.
In that project, there is a file under src/main/resources, cagetory.xml,
which has the information for the features in this update site.
You probably won't need to update this file, unless you're adding
some completely new features. If all you're doing is releasing new
versions of existing features, you can leave this file alone, because
the version information is added during resource filtering based on the
the update site's own POM version.
Any new features must be added to one (or more) categories, for them to be "visible".
If you are changing categories, this is where that is done, also; but that
is probably a rare occurrence.
How the update site build works
The build process packs (just the) new plugin Jars, and combines these
and the new feature Jars with the existing update site (which
probably has older versions of the features and plugins), and generates
new metadata for the new plugins and appends this to any
existing metadata.
- The distribution SVN's .../dev/... spot is updated so that the
part of it which corresponds to the Eclipse update sub site is replaced by
an SVN copy of the .../release/... spot.
- The existing subsite is checked out of the (now current) .../dev/... spot in the distribution SVN.
- The new features and plugins
are collected using the maven dependency plugin from "official" levels using
maven artifact coordinates
- The new plugin jars are packed
- New metadata for the features and plugins is generated and appended to the
the existing metadata for the older versions
- New catogory information for the features is generated and appended to the
existing category information
- The new features and plug jars are checksummed and (if the Apache Release profile is in effect)
signed
- The result is left in the target/eclipse-update-site/[subsite] directory of the
update site project.
- (Optional) You may want to do an SVN checkin on all the artifacts under
target/eclipse-update-site/[subsite] - they will go into the distribution SVN .../dev/... spot.
If you expect to do a lot of release candidates, you may want to avoid doing this and instead
just copy the results to some other spot for PMC members to check; this is because multiple
releases will take up extra space in the distribution SVN.
If the update consists of just new versions of the the existing features and plugins,
it may not be necessary to update the POM for the update-site generation (other than
to insure its version information is what you want the feature/plugin versions to be).
Releasing a new Composite Update Site
Normally, the composite update site doesn't change. It changes when new sub-sites
are created, usually for new projects having Eclipse components.
To change the Composite site, update the POM to a new version number (it's numbered
like build artifacts, with a simple incrementing integer). Then update the buildCompositeRepository.xml
file at the top level to reflect the changes.
The build is done using the same techniques as the other update site: the dist .../release/... part is
copied to the .../dev/... and that's svn-checked-out. Then the build runs the special ant tasks to generate
the composite Jars from the buildCompositeRepository.xml. If you use the -Papache-release parameter on the mvn
command line, the build will generate the checksums and do the gpg signing of the artifacts. The results
are left in the tartet/eclipse-update-site for this project, ready to be svn-switched back to the dist .../release/...
point and the changes committed.
UIMA's Eclipse Update Site