UIMA project logo
Downloads
Apache UIMA

Search the site

 Downloading Apache UIMA™

Using via Maven dependency

Most people use Apache UIMA through the artifacts we distribute on Maven Central. A dependency on the Apache UIMA Java SDK Core artifact looks like this:

<dependency>
  <groupId>org.apache.uima</groupId>
  <artifactId>uimaj-core</artifactId>
  <version>3.5.0</version>
</dependency>

Here you can find an overview of all the artifacts on Maven Central.

Eclipse Tooling Update Site

https://downloads.apache.org/uima/eclipse-update-site-v3/.

If you're doing this for the first time, you may wish to consult the much more verbose instructions on the UIMA Documentation page.

Apache UIMA release packages

Apache UIMA is distributed as source and binary (ready-to-use) packages. These are available in zip, tar.gz and sometimes, tar.bz2 archive formats. Please note that the tar.* archives contain file names longer than 100 characters and have been created using GNU tar extensions. Thus they must be untarred with a GNU compatible version of tar. It is good practice to verify the integrity of the distribution files.

Current mirror:
Artifact Release
Notes
Binary Source Release Date

UIMA Java SDK 3.5.0

zip [asc] [sha512]
tar.gz [asc] [sha512]
zip [asc] [sha512]
06-Nov-2023

uimaFIT 3.5.0

zip [asc] [sha512]
13-Nov-2023

UIMA Ruta 3.4.1

zip [asc] [sha512]
08-Feb-2024

UIMA Java CAS JSON I/O 0.5.0

zip [asc] [sha512]
06-Mar-2023

 Archived Releases

Older releases of Apache UIMA artifacts can be found here. We highly recommend to not use those releases but upgrade to UIMA's latest release.

Older update sites for UIMA Eclipse tooling are at Apache's archive for releases, and you can find links to them here.

 Verifying a Release Download

Signature Files

You may be wondering what those .asc, .md5 and .sha1 files on the download pages are good for. They are signature files that let you verify the integrity and origin of the distribution artifacts (zip files, compressed archives) that you have downloaded. The signatures come in two varieties. The .md5 and .sha1 files contain MD5 and SHA1 checksums, respectively. The main purpose of those files is to let you verify the integrity of your release artifact. You can use a tool to generate the same kind of checksum and check that it's the same checksum as the one you downloaded. If the checksums agree, you can be sure that your archive did not get corrupted during transmission.

The .asc files are so-called detached, ASCII-armored PGP signatures. They let you do the same thing as the MD5 and SHA1 signatures, but they let you do something in addition: you can use these signatures to verify that the release artifacts were signed by a certain, trusted source. The .asc files contain checksums that were encrypted with the private PGP key of the release manager responsible for the release. This is useful if you received the release files from some arbitrary source, and you would like to be sure that what you have there is really a UIMA release (and not something containing a virus, for example). You can then download the corresponding public key from a trusted source, and use it to verify not only the integrity of the file, but that it is actually the file the release manager signed in the first place. Anybody can tamper with a released file and create a new checksum, but they can't fake the .asc file so it will work with the public key of the release manager.

If you would like to verify your UIMA distribution or not is up to you, but unless you do it, you cannot be sure that you have an uncorrupted copy. The next section will tell you how can use each type of signature file.

Using GnuPG to Verify Release Files

Start by downloading and installing GnuPG, an implementation of OpenPGP. There are many tools for verifying MD5 and SHA1 checksums, here's the GnuPG way for MD5:

gpg --print-md MD5 <ReleaseFile>

and for SHA1:

gpg --print-md SHA1 <ReleaseFile>

You can simply compare the resulting checksum to the one contained in the <ReleaseFile>.md5 or <ReleaseFile>.sha1 checksum file. Use diff or your eyes, the signatures are short.

A better way of verifying a distribution file is to use the PGP signature provided in the .asc files. To be able to use the PGP signature files, you need to obtain the UIMA developers' public keys from a trusted source. The keys do come with the distribution as well, but obviously using those is not a good way to ascertain the pedigree of a distribution. Instead, get the keys from the main Apache distribution site (not a mirror), or directly out of the UIMA SVN repository.

(Right click the following links, and select save link/target as ...)

Depending how sure you want to be that those keys are really the ones you can trust, you may think of even safer ways to obtain them (for example, go to ApacheCon and get them personally).

Once you have downloaded the KEYS file, you can import it into your GnuPG key registry with

gpg --import KEYS
Check what your key registry contains with
gpg --list-keys

To verify a release file, cd to the directory with the release and run

gpg --verify <fileName>.asc
for each file you would like to verify. The output should contain something like this:
gpg: Good signature from "Thilo Goetz (CODE SIGNING KEY) <twgoetz@apache.org>"

Verifying MD5 checksums

To verify an MD5 checksum, after downloading an artificat, use a command to generate the md5 checksum of the downloaded artifact. On Linux or using Cygwin on Windows, this can be done using the command "md5sum" followed by the path to the artifact. There are also programs you can download from the web to do this computation.

Once you have the sum, go to this page at Apache: https://people.apache.org/~henkp/cgi-bin/md5.cgi and copy / paste the generated checksum into the box. The script on this page will then look up that checksum in a table it keeps for all artifacts from Apache distributions, and verify the checksum is valid.

More details on Release Signing

Further information on how all this works can be found at https://www.apache.org/dev/release-signing.html