Following routine can fail if JAR is constructed with "filesonly" approach (as can be done through ANT).

addPackages(true, "groovy")

This invocation involves URLPackageScanner, which down under calls classLoader.getResources(name).

I came across this behaviour while working on Groovy 2.0 support for Spock Test Runner. First I thought that there is some essential difference in the MANIFEST file. But after repacking (jar xvf and then jar cvf) including the same manifest file the test was passing. Here's the isolated problem shared as mvn project on github.

Interestingly enough those two JARs are identical in terms of the content (at least based on what pkgdiff is showing), but they were still different in the size. Then I tried zipinfo, and here's when I saw the real problem. Original groovy JAR was packaged without the directory entries, and therefore, according to this bug evaluation from Sun the JAR is not found through the classLoader.getResource() call. To quote:

In general, Class.getResource() is intended to access file based resources
(on the filesystem, or from jar files or wherever..) It is not specified
what the effect of accessing a directory entry is, and therefore this
behavior can not be expected to be the same across different URL schemes.

As a solution we should scan all the jars from the classpath directly in case when classLoader.getResource() will return ambiguous null (as it can also mean that we don't have sufficient privileges according to the javadoc).