maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch (JIRA)" <>
Subject [jira] Commented: (MNG-4810) Maven cannot build if loaded in a classloader that is not backed by a real JAR file / classpath
Date Thu, 16 Sep 2010 20:28:43 GMT


Stuart McCulloch commented on MNG-4810:

This should already be fixed in the RC1 build - it now uses the more classloader friendly
getResources() to find components.xml. (The other method called findEntries is used when the
container is scanning for files according to a pattern like *.class, in which case you can't
use getResources and must rely on introspecting the URLs - but for M3 we're still using XML
directed injection)

> Maven cannot build if loaded in a classloader that is not backed by a real JAR file /
> -----------------------------------------------------------------------------------------------
>                 Key: MNG-4810
>                 URL:
>             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
>         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:
For more information on JIRA, see:


View raw message