You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Lincoln Baxter, III (JIRA)" <ji...@codehaus.org> on 2010/09/16 19:49:32 UTC
[jira] Created: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
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
[jira] Commented: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
Posted by "Lincoln Baxter, III (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235541#action_235541 ]
Lincoln Baxter, III commented on MNG-4810:
------------------------------------------
The new RC1 release seems to have found its way into cental now. It looks like everything is working, though the APIs changed significantly and I had to hunt and seek to figure out which objects Maven wanted populated (was getting nullpointers everywhere.)
> 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
[jira] Commented: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235533#action_235533 ]
Benjamin Bentmann commented on MNG-4810:
----------------------------------------
Source and binary bundles of RC1 are available from:
https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/
> 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
[jira] Commented: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
Posted by "Lincoln Baxter, III (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235523#action_235523 ]
Lincoln Baxter, III commented on MNG-4810:
------------------------------------------
BTW - it probably goes without saying that this was not an issue in Maven 3 Beta 2 :)
> 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
[jira] Closed: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
Posted by "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
[jira] Commented: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
Posted by "Stuart McCulloch (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MNG-4810) Maven cannot build if loaded in a
classloader that is not backed by a real JAR file / classpath
Posted by "Lincoln Baxter, III (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235532#action_235532 ]
Lincoln Baxter, III commented on MNG-4810:
------------------------------------------
Sounds promising! Where can I find a maven repository with these artifacts? (I'd prefer not to try to hack the distribution jars into my local repo ;))
> 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