UIMA project logo
UIMA's Eclipse Update Site
Apache UIMA

Search the site

 UIMA's Eclipse Update Site

Introduction

The Apache UIMA™ project maintains an Eclipse update site as part of its prebuilt artifacts. The information on this page is mainly for developers, and documents how this update site is managed.

Over time, the update site ends up containing various Eclipse features and their plugins, at different "versions". It uses the (evolving) Eclipse standard mechanisms to install whatever version a user might require.

Because of this, the update site itself keeps "older" versions. Every time a new release is made which includes one or more new versions of some Eclipse features/plugins, the new artifacts are added to the set of existing (and perhaps, older versions of) feature and plugins.

P2

At some point in the evolution of the Eclipse update site mechanisms, the "P2" approach for Eclipse update sites was developed, and became the preferred way to package update sites. It has some changes (among others):

  • It adds to the normal metadata about components, the detailed version and dependency information contained in the manifest of the OSGi component JARs. This is a finer-grained versioning system in which version information is associated with Java Packages, in contrast to the entire contents of a Jar being the entity which is versioned.

    Some tooling, such as http://eclipse.org/tycho/Tycho, need this finer-grained information to resolve dependencies.

  • It continues the previous approach of putting a copy of the metadata in a separately downloaded file (formerly, the digest.zip). In P2 this is now in 2 files: content.xml and artifacts.xml (these files are actually made into compressed Jars).
  • The former update site files: site.xml, and digest.zip are no longer needed.

Some of the UIMA plugin projects now need to have the "high-fidelity" resolution of software dependencies that comes with the P2 repositories.

As of January 2013, we are converting to the P2 style of update sites, and are no longer building the update site for pre-P2 style because P2 support has been in Eclipse for several years (since mid 2008).

Composite Update Sites

Update sites can be composite. A composite update site merely includes pointers to other update sites. The installation procedure combines all of the composite update sites mentioned in the top level composite description into one, for purposes of displaying and working with it. We use the composite mechanism to make maintenance of independently developed features more isolated; when a new version of a sub-site is developed, updates are localized to just that sub-site. The composite update site can also be separately maintained - it needs to change only when new sub-sites are added.

Our subsites are designed to be kept in named subfolders of the main update site (.../dist/uima/eclipse-update-site).

We currently have sub-sites for

  • uimaj - base Java UIMA SDK tools and runtime
  • uima-as - addons for the base tooling to add the deployment descriptor editor, and uima-as runtime
  • TextEditor (coming soon)

The update site looks like:

.../dist/uima/eclipse-update-site
                                 /compositeArtifacts.jar
                                 /compositeContent.jar
                                 /uimaj
                                       /artifacts.jar
                                       /content.jar
                                       /features/.... all features
                                       /plugins/.... all plugins
                                 /uima-as
                                       /artifacts.jar
                                       /content.jar
                                       /features/.... all features
                                       /plugins/.... all plugins                                      

Layout and Versioning

The main Eclipse update site (which only has composite pointers to subsites) is kept with the general UIMA build tooling in http://svn.apache.org/repos/asf/uima/build/trunk/uima-eclipse-composite-update-site.

Feature and Plugin projects associated with particular parts of the UIMA project (such as the Rule Engine Workbench, or Java Base SDK, etc.), reside within those major components.

Each subsite is typically built with its associated component. It is therefore reasonable to version these together with the component. So, for example, the UIMA Java SDK, released at version 2.4.0, will have the plugin and feature projects for it also at 2.4.0.

The project in the build tools, uima-eclipse-composite-update-site, is only rebuilt when a new subsite is added; it has incrementing version numbers.

The update-site packaging of released components is released as part of the underlying release of the components it packages; it doesn't (normally) have a separate "vote". When doing a componet release, the release manager should build and make available for testing the update (sub) site (and a new version of the composite update site, if that is being added to). When the release is accomplished, the release action is then a simple SVN copy from the dev/ to the release/ spot in the distribution SVN.

How to Change the Update Site

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, 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 artifacts.

Running 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 distribution.

Earlier Optimizations (Historical)

The first UIMA Eclipse update sites were optimized by the then-current approach to optimization. This included 2 special things:

  • "super-duper" packing of the jar files using some new compression utilities that came with Java 5.
  • A separate copy of all the metadata needed for initial processing by the Eclipse update mechanism - put into a compressed "digest.zip".
  • See http://wiki.eclipse.org/Update_Site_Optimization, which describes the design goals for this.

    But note that the information on this page is now out of date, and has been superseded by a second version of update site packaging. In fact, the previously available headless Eclipse application, org.eclipse.update.core.siteOptimizer, is no longer part of Eclipse releases.

Links and References

Here are links to more information; there are many (partially) out-of-date websites which are misleading but these links (as of January, 2013, seem up to date.)