Since upgrading some projects to the new Spring Framework 3.0, and perhaps just coincidentally noticed while updating other JAR files, I’ve noticed a number of warnings from Ant during my activities that indicate that JAR files are not being found. Most peculiarly, the warnings are for JAR files that are not used nor are they anywhere in the classpath.

What’s happening is that some JAR file that is being used contains a Class-Path element in its MANIFEST.MF file that isn’t satisfied. It’s probably the case that the expected JAR has been replaced with a different version or named file (like no more spring-core.jar but spring-release-muckity-muck.jar). This gives the warning, but the compiler and running app don’t bark because they find the classes when everything is done, or it turns out that the desired classes aren’t used in the program in question.

Like so many things in life, there are only two solutions. Well, three, as you could accept the warnings.

Harder: Find an updated JAR for the one complaining (which means identifying the JAR that is complaining) or otherwise make the Ant classpath contain the named JAR. It may also mean satisfying the warning by adding JAR files that satisfy the JAR Class-Path elements even if the application isn’t using any classes from it.

Easier: In the Ant script, find the -Xlint bit (in the look for and change it to “-Xlint:-path” to suppress the warnings. If the javac work is done externally to the Ant script (say by some more difficult than needs to be script), look in that location and add the suppression to Xlint.

The harder option, when completely satisfied, eliminates the potential error condition by getting all of the versions right and ensuring that any potentially missing class is no longer missing, but will be messier to maintain and can add unwanted extra baggage. This is, strictly speaking, the more correct way to handle the problem.

The easier option still has the warning, but suppresses it from the output. This method relies on tests or running the application to indicate missing JAR dependencies (as ClassNotFoundExceptions will occur). Since the warning is arguably wrong, as the desired classes may be in an updated but differently named JAR, or they may not be used at all in this implementation, I’m all for suppressing it and letting a test fail if I’m actually missing a JAR file or class from within.