[
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
