Testing Release Candidates

This page has information for testing release candidates.

Prepare for testing by going to building-uima and doing the one-time setup, if you haven't done this already. This includes installing Maven 3.

Overview

See "What must be included in a release". To approve a release, it is good to do the following tests:

svn export the SVN tag for the code, and compare this to the unzip of the source-release. These should be the same, except for some minor things; use your good judgement.

Check building from source: In your local .m2, delete the files being built (a good thing is to delete the "uima" directory), then get the source-release, unzip it, and run mvn install at the top level, to see if it builds.

Check that the license and notice files are present in the source and binary distributions, and that the binary distributions have license/notice parts incorporated into the top-level license/notice files for any included artifacts being distributed.

Check that the Jars have appropriate license / notice files for things contained within them.

When an Eclipse update site is being released, try installing that into a fresh unzip of Eclipse 3.7.2 or later, and then verify the functionality seems present. When installing, it should show the standard licensing boilerplate, that refers (like the Eclipse user agreement) to embedded license/notice files.

Testing a source-release

Download the ....source-release.zip file from the staging repository, for the top-most released artifact. (Multimodule releases will have one top-level release artifact).

Unzip.

cd to the top level release artifact directory.
Run
mvn install
to verify it builds from source.
Inspect the unzipped source to verify license/notice files are in place.

Run whatever further tests might be appropriate for the release.

Setup for testing - adding the Staging repository for Maven builds

If you want Maven to be able to find the artifacts in the staging repository during its build processing, follow the next instructions, and then add this additional parameter to your "mvn" commands: -Pstaged-release.

This is sometimes needed to test new build tooling, for example. The test would be done by (temporarily) updating some code to depend on the new version, and then trying to build it. In this case, with the -Pstaged-release added, Maven would be able to find the staged artifacts.

To enable Maven to find artifacts in the staging repository location:
Update your Maven "settings.xml" file located in the directory containing your local Maven repository; in Windows, this is c:\Documents and Settings\<your-userid>\.m2\settings.xml. The idea is to add a repository spec called "staged-release" that points to the staging repository of interest. This changes for each staged release - the right url will be provided in the [VOTE] email). Here's a sample settings file, with just this profile element in it:
<settings xmlns="https://maven.apache.org/POM/4.0.0"
  xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/settings-1.0.0.xsd">

  <profiles>
    <profile>
      <id>staged-release</id>
      <repositories>
        <repository>
          <id>staged-release</id>
          <url>https://repository.apache.org/content/repositories/orgapacheuima-xxx/</url>
        </repository>       
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>staged-release</id>
          <url>https://repository.apache.org/content/repositories/orgapacheuima-xxx/</url>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>

</settings>
Note: The url element above is just a sample; each release will have its own unique staging repository name, which is provided in the [VOTE] email. Replace the .../orgapacheuima-xxxxxx with the correct url.