[jira] Closed: (MNG-4810) Maven cannot build if loaded in a classloader that is not backed by a real JAR file / classpath

["Benjamin Bentmann (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Bentmann closed MNG-4810.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0
         Assignee: Benjamin Bentmann

Fixed by [r997467|http://svn.apache.org/viewvc?view=revision&revision=997467].

> Maven cannot build if loaded in a classloader that is not backed by a real JAR file / classpath
> -----------------------------------------------------------------------------------------------
>
>                 Key: MNG-4810
>                 URL: http://jira.codehaus.org/browse/MNG-4810
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 3.0-beta-3
>         Environment: Mac OSX & Linux, Java 1.6, Maven 3 beta 3
>            Reporter: Lincoln Baxter, III
>            Assignee: Benjamin Bentmann
>             Fix For: 3.0
>
>         Attachments: arquillian-maven-bug.tar.gz
>
>
> Maven fails to find required class files (resulting in null pointer exceptions) because the ClassLoader implementation in which it was loaded does not meet maven's assumptions of what type of information a ClassLoader URL should return.
> (From another perspective, that ClassLoader does not behave like a normal ClassLoader, but maven should probably not be contstrained to classloaders that provide their information as if they were backed by a JAR file; not all classloaders are going to use those semantics, as provided in this example, when the URLClassSpace instance loaded by the DefaultPlexusContainer attempts to read the "/MANIFEST.ML" out of a non-jar-based classloader.
> Please run example tests in attached project.
> I attempted to patch this by ignoring exceptions when attempting to pull manifests, but it appears that maven uses those manifests to populate some kind of bean container (I'm guessing guice which is abstracted via a plexus facade.)
> Then I attempted to modify the URLClassLoader instance in which the application was actually running, in order to provide a manifest, but it appears that maven is still just processing "Class-Path" elements and attempting to source those files directly, which might not work (but I had trouble getting this to work, so it may just have been something I was doing wrong.)
> If I knew more about why maven was trying to use the classloader in this way, I might be able to give more insightful thought into the nature/potential solutions of/for this issue. I do know that maven is making some assumptions about how the internals of classloaders are working, here in URLClassSpace:
> `
>     private static String[] getClassPathEntries( final URL url )
>         throws IOException
>     {
>         final URL manifestURL;
>         if ( url.getPath().endsWith( "/" ) )
>         {
>             manifestURL = new URL( url, MANIFEST_ENTRY );
>         }
>         else
>         {
>             manifestURL = new URL( "jar:" + url + "!/" + MANIFEST_ENTRY );
>         }
>         final InputStream in = manifestURL.openStream();
>         try
>         {
>             final String classPath = new Manifest( in ).getMainAttributes().getValue( "Class-Path" );
>             return null != classPath ? classPath.split( " " ) : NO_ENTRIES;
>         }
>         finally
>         {
>             in.close();
>         }
>     }
> `
> I hope I have provided enough information, and that the attached test-case provides useful.
> Just run the attached project via 'mvn test' or 'mvn package' and you'll see the issue.
> Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira