[
http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235530#action_235530
]
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 / 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
> 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
