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

[Andrew Rubinger (JIRA)]

    [ https://issues.jboss.org/browse/SHRINKWRAP-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761842#comment-12761842 ] 

Andrew Rubinger commented on SHRINKWRAP-446:
--------------------------------------------

Scanning all JARs on the CP is a solution I'd like to avoid where possible; it's a lengthy task with arbitrarily large (and uncapped) input.

So "addPackages" requires the CL layer to know what it's capable of loading...thinking on this.  More ideas welcome.
                
> 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