Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.4
-
Fix Version/s: 2.1.0
-
Component/s: Plugins and Lifecycle
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
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.
Issue Links
| This issue is related to: | ||||
| PLX-428 | Properly report class loading errors upon component lookup |
|
|
|
common nuisance error - wuld be good to fix