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:
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, run the Eclipse category editor on the file
category.xml and update the categories. You must add any new
features to one (or more) categories, for them to be "visible";
this includes new versions of existing features. If you are
changing categories, this is where that is done, also; but that
is probably a rare occurrence.
Each individual update site "build" will use its pom to pull into its .../target/eclipse-update-site
the complete set of features and plugins for that sub-site.
It does this using information specified in the POM,
for all versions of the features and plugins.
Therefore, you must edit the POM to specify the new versions
of any of the features and plugins being released, adding those
to the lists inside of the build step that copies the plugin and feature
mvn package on the individual update site pom will produce a
P2 update site in its /target/eclipse-update-site. When releasing, the
contents of this directory needs to be copied into the appropriately
named subfolder for this sub-site in the release spot for UIMA