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

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