Java Library Dependencies

myGrid components use many APIs implemented as Java Archives (JAR files) by third-party open source developers. For convenience, we store these built JAR files in our CVS JAR repository.

Adding JAR files to the repository

Our experience to date has been that we need to use different versions of certain JAR files concurrently in different components. To permit this behaviour, it is our policy to include an appropriate release identifier as part of the JAR file's name: for example somelib-1.3.1.jar. This has the following advantages:

• Each JAR file's version is immediately obvious
• Multiple versions can still co-exist

one disadvantage:

• Submitters must use the correct version identifier

and one feature that is probably an advantage but can seem like a disadvantage to the developer:

• Upgrading to a more recent library version is an explicit task. Because the developer must edit their build file to pick up a new version, there will be no 'silent' and possibly error-introducing change to the component's environment

Our previous scheme, using the suppliers' names unchanged, made it difficult to work with mulitple concurrent versions of the same libary: we had to cirvumvent it either by storing new versions local to the project (the MIR does this currently) or breaking the rule and renaming the conflicting JAR (often by adding the version number!).

Choosing which JAR file versions to use

There are no hard-and-fast rules, except that the JAR file must do what you need it to do in the context of your component and the other third-party libraries. Generally:

• Prefer supported, 'official', releases to beta releases
• Prefer beta releases to alphas
• Prefer alphas to supplier's nightly/weekly snapshots
• Prefer supplier snapshots to build-your-own current-head-of-CVS
• If it ain't broke, don't fix it

Incorporating version identifiers into JAR file names

It may be necessary to rename a JAR file to incorporate a version identifier. Try the following heuristic:

1. If the version you need is available from the Maven repository, get it from there (Maven requires JAR files to include a version identifier)
2. If the supplier already includes a version number in the JAR file name (e.g. somelib-1.3.1.jar or somelib_1-3-1.jar) use the supplier's name unchanged)
3. If the JAR file name does not include a version identifier, but is taken from a download from the original developer that does (e.g. somelib.jar from somestuff-1.3.1.zip), append the download's version part (giving e.g. somelib-1.3.1.jar)
4. If the JAR is build from CVS head, use a version -CVS-extractiondate (e.g. somelib-CVS-2005-05-29.jar)

CVS Commit messages for JAR files

When committing a JAR file, use the commit message to indicate the product the JAR file comes from and its website, e.g.

  cvs commit somelib-1.3.1 -m "SomeStuff, http://somestuff.sourceforge.net"

Using existing, no-version-tag, JAR files

The repository contains some libraries with no version component in their names. If your component uses one of these libraries without a problem, there is no need to change. When you need to upgrade one of these libraries, you should choose or add a library that does follow the version-tag convention.

If your component has not hitherto used one of these libraries, but now needs to, do not use a no-version-tag file but choose or add a library that does follow the version-tag convention. (It is unlikely that these old files give any simple clue as to their version: you won't know which sources you need to debug in case of problems).

Dependencies of dependencies

The following topics identify JAR dependencies for relevant versions of packages used by several myGrid components. The given JAR file names correspond to those in the myGrid third-party library repository.

• Apache Axis: JarDependenciesForAxis

• HP Jena: JarDependenciesForJena

• Apache Xerces: JarDependenciesForXerces

Note that we don't have any solutions for handling different JAR file versions within a single component: if a third-party library needs to use one version of a second library, and your component (or a third library) needs a different version, then you've got problems that may need some ad hoc ingenuity to solve. Sorry.

-- NickSharman - 10 Nov 2004, 06 Jun 2005