[shrinkwrap-issues] [JBoss JIRA] (SHRINKWRAP-446) Incorrect behaviour of adding packages by name

[Bartosz Majsak (JIRA)]

Bartosz Majsak created SHRINKWRAP-446:
-----------------------------------------

             Summary: Incorrect behaviour of adding packages by name
                 Key: SHRINKWRAP-446
                 URL: https://issues.jboss.org/browse/SHRINKWRAP-446
             Project: ShrinkWrap
          Issue Type: Bug
          Components: impl-base
         Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) (does not really matter though)
Java version: 1.7.0_15, vendor: Oracle Corporation
OS name: "linux", version: "3.2.0-38-generic", arch: "amd64", family: "unix"
Arquillian 1.0.3.Final
Shrinkwrap 2.0.0-alpha-3
            Reporter: Bartosz Majsak


Following routine can fail if JAR is constructed with "filesonly" approach (as can be done through ANT).
{code:java}
addPackages(true, "groovy")
{code}
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|https://github.com/bartoszmajsak/groovy-classloading].

Interestingly enough those two JARs are identical in terms of the content (at least based on what [pkgdiff|http://pkgdiff.github.com/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|http://bugs.sun.com/view_bug.do?bug_id=4761949] the JAR is not found through the {{classLoader.getResource()}} call. To quote:
{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.
{quote}

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).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira