You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Aaron Digulla (JIRA)" <ji...@codehaus.org> on 2006/12/07 16:21:41 UTC
[jira] Created: (MNG-2690) DefaultPluginManager.getConfiguredMojo()
doesn't handle NoClassDefFoundError correctly
DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
--------------------------------------------------------------------------------------
Key: MNG-2690
URL: http://jira.codehaus.org/browse/MNG-2690
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.4
Reporter: Aaron Digulla
If maven tries to download a file which doesn't exist and it believes there is no other place where it can get the file, you can have the situation that Maven tries to invoke a Plugin without a complete classpath. In the log, you'll see something like this:
Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
15K downloaded
As you can see, Maven tries to download the POM from a different site than the JAR. Now, the classpath of the JAR is incomplete because the POM is missing. Things get really nasty when Maven tries to access the plugin. You'll get:
java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
which tells you exactly nothing since you have no idea who wants that class. The cause of the problem is that PlexusContainer doesn't catch errors (well, Java says you shouldn't but the user would really like to see what's going on).
My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo() (around line 530):
catch ( NoClassDefFoundError e )
{
throw new PluginManagerException( "Unable to find the mojo '" + mojoDescriptor.getRoleHint() +
"' in the plugin '" + pluginDescriptor.getPluginLookupKey() + "' because of NoClassDefFoundError:", e );
}
This way, I get at least an idea which plugin is causing the problem.
But I guess the container should be fixed to catch these errors.
--
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-2690)
DefaultPluginManager.getConfiguredMojo() doesn't handle
NoClassDefFoundError correctly
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166291#action_166291 ]
John Casey commented on MNG-2690:
---------------------------------
It would be good if we could get even just a stack trace to start figuring out where to put this sort of code. Line 530 isn't in getConfiguredMojo() anymore, so I'm not entirely sure where to put this fix.
I'm guessing it's a whole other discussion whether we can put together an integration test for this, but it's important to try if we can.
I'm not sure we can get this done for 2.1.0, given the scant information in the issue.
> DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
> --------------------------------------------------------------------------------------
>
> Key: MNG-2690
> URL: http://jira.codehaus.org/browse/MNG-2690
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.4
> Reporter: Aaron Digulla
> Assignee: John Casey
> Fix For: 2.1.0
>
>
> If maven tries to download a file which doesn't exist and it believes there is no other place where it can get the file, you can have the situation that Maven tries to invoke a Plugin without a complete classpath. In the log, you'll see something like this:
> Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
> Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
> 15K downloaded
> As you can see, Maven tries to download the POM from a different site than the JAR. Now, the classpath of the JAR is incomplete because the POM is missing. Things get really nasty when Maven tries to access the plugin. You'll get:
> java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> which tells you exactly nothing since you have no idea who wants that class. The cause of the problem is that PlexusContainer doesn't catch errors (well, Java says you shouldn't but the user would really like to see what's going on).
> My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo() (around line 530):
> catch ( NoClassDefFoundError e )
> {
> throw new PluginManagerException( "Unable to find the mojo '" + mojoDescriptor.getRoleHint() +
> "' in the plugin '" + pluginDescriptor.getPluginLookupKey() + "' because of NoClassDefFoundError:", e );
> }
> This way, I get at least an idea which plugin is causing the problem.
> But I guess the container should be fixed to catch these errors.
--
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] Work started: (MNG-2690)
DefaultPluginManager.getConfiguredMojo() doesn't handle
NoClassDefFoundError correctly
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on MNG-2690 started by John Casey.
> DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
> --------------------------------------------------------------------------------------
>
> Key: MNG-2690
> URL: http://jira.codehaus.org/browse/MNG-2690
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.4
> Reporter: Aaron Digulla
> Assignee: John Casey
> Fix For: 2.1.0
>
>
> If maven tries to download a file which doesn't exist and it believes there is no other place where it can get the file, you can have the situation that Maven tries to invoke a Plugin without a complete classpath. In the log, you'll see something like this:
> Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
> Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
> 15K downloaded
> As you can see, Maven tries to download the POM from a different site than the JAR. Now, the classpath of the JAR is incomplete because the POM is missing. Things get really nasty when Maven tries to access the plugin. You'll get:
> java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> which tells you exactly nothing since you have no idea who wants that class. The cause of the problem is that PlexusContainer doesn't catch errors (well, Java says you shouldn't but the user would really like to see what's going on).
> My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo() (around line 530):
> catch ( NoClassDefFoundError e )
> {
> throw new PluginManagerException( "Unable to find the mojo '" + mojoDescriptor.getRoleHint() +
> "' in the plugin '" + pluginDescriptor.getPluginLookupKey() + "' because of NoClassDefFoundError:", e );
> }
> This way, I get at least an idea which plugin is causing the problem.
> But I guess the container should be fixed to catch these errors.
--
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-2690) DefaultPluginManager.getConfiguredMojo()
doesn't handle NoClassDefFoundError correctly
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey closed MNG-2690.
---------------------------
Resolution: Fixed
> DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
> --------------------------------------------------------------------------------------
>
> Key: MNG-2690
> URL: http://jira.codehaus.org/browse/MNG-2690
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.4
> Reporter: Aaron Digulla
> Assignee: John Casey
> Fix For: 2.1.0
>
>
> If maven tries to download a file which doesn't exist and it believes there is no other place where it can get the file, you can have the situation that Maven tries to invoke a Plugin without a complete classpath. In the log, you'll see something like this:
> Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
> Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
> 15K downloaded
> As you can see, Maven tries to download the POM from a different site than the JAR. Now, the classpath of the JAR is incomplete because the POM is missing. Things get really nasty when Maven tries to access the plugin. You'll get:
> java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> which tells you exactly nothing since you have no idea who wants that class. The cause of the problem is that PlexusContainer doesn't catch errors (well, Java says you shouldn't but the user would really like to see what's going on).
> My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo() (around line 530):
> catch ( NoClassDefFoundError e )
> {
> throw new PluginManagerException( "Unable to find the mojo '" + mojoDescriptor.getRoleHint() +
> "' in the plugin '" + pluginDescriptor.getPluginLookupKey() + "' because of NoClassDefFoundError:", e );
> }
> This way, I get at least an idea which plugin is causing the problem.
> But I guess the container should be fixed to catch these errors.
--
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] Updated: (MNG-2690) DefaultPluginManager.getConfiguredMojo()
doesn't handle NoClassDefFoundError correctly
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated MNG-2690:
------------------------------
Affects Version/s: (was: 2.1.0-M3)
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1.0-M3
> DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
> --------------------------------------------------------------------------------------
>
> Key: MNG-2690
> URL: http://jira.codehaus.org/browse/MNG-2690
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.4
> Reporter: Aaron Digulla
> Fix For: 2.1.0-M3
>
>
> If maven tries to download a file which doesn't exist and it believes there is no other place where it can get the file, you can have the situation that Maven tries to invoke a Plugin without a complete classpath. In the log, you'll see something like this:
> Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
> Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
> 15K downloaded
> As you can see, Maven tries to download the POM from a different site than the JAR. Now, the classpath of the JAR is incomplete because the POM is missing. Things get really nasty when Maven tries to access the plugin. You'll get:
> java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> which tells you exactly nothing since you have no idea who wants that class. The cause of the problem is that PlexusContainer doesn't catch errors (well, Java says you shouldn't but the user would really like to see what's going on).
> My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo() (around line 530):
> catch ( NoClassDefFoundError e )
> {
> throw new PluginManagerException( "Unable to find the mojo '" + mojoDescriptor.getRoleHint() +
> "' in the plugin '" + pluginDescriptor.getPluginLookupKey() + "' because of NoClassDefFoundError:", e );
> }
> This way, I get at least an idea which plugin is causing the problem.
> But I guess the container should be fixed to catch these errors.
--
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] Updated: (MNG-2690) DefaultPluginManager.getConfiguredMojo()
doesn't handle NoClassDefFoundError correctly
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated MNG-2690:
------------------------------
Affects Version/s: 2.1.0-M3
common nuisance error - wuld be good to fix
> DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
> --------------------------------------------------------------------------------------
>
> Key: MNG-2690
> URL: http://jira.codehaus.org/browse/MNG-2690
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.4, 2.1.0-M3
> Reporter: Aaron Digulla
> Fix For: Reviewed Pending Version Assignment
>
>
> If maven tries to download a file which doesn't exist and it believes there is no other place where it can get the file, you can have the situation that Maven tries to invoke a Plugin without a complete classpath. In the log, you'll see something like this:
> Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
> Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
> 15K downloaded
> As you can see, Maven tries to download the POM from a different site than the JAR. Now, the classpath of the JAR is incomplete because the POM is missing. Things get really nasty when Maven tries to access the plugin. You'll get:
> java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> which tells you exactly nothing since you have no idea who wants that class. The cause of the problem is that PlexusContainer doesn't catch errors (well, Java says you shouldn't but the user would really like to see what's going on).
> My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo() (around line 530):
> catch ( NoClassDefFoundError e )
> {
> throw new PluginManagerException( "Unable to find the mojo '" + mojoDescriptor.getRoleHint() +
> "' in the plugin '" + pluginDescriptor.getPluginLookupKey() + "' because of NoClassDefFoundError:", e );
> }
> This way, I get at least an idea which plugin is causing the problem.
> But I guess the container should be fixed to catch these errors.
--
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