Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: 1.1-beta-1
-
Fix Version/s: 1.1-beta-1
-
Component/s: core
-
Labels:None
-
Number of attachments :
Description
I was doing some tests with Maven 1.1 (from CVS) and got a nasty NPE. After debugging it, I concluded it was caused while reading the maven-tasks-plugin, which apparently has a bad <resource> tag inside its POM. But even if the problem is on the plugin's POM, maven should handle the issue better, otherwise it would be a nightmare to migrate old projects from 1.0 to 1.1
So, I'm providing a simple test case for this issue (and will try to provide a patch fixing it as well); running it raises the following exception:
$ maven
__ __
| \/ | __ Apache_ ___ | |||||
| \/ | / ` \ V / -) ' \ ~ intelligent projects ~ | |||||
| _ | _,_ | _/___ | _ | _ | v. 1.1-SNAPSHOT |
|---|
plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer pres
ent
Cache invalidated due to out of date plugins
org.apache.maven.MavenException: Unknown error reading project
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:146)
at org.apache.maven.plugin.JellyScriptHousing.getProject(JellyScriptHous
ing.java:105)
at org.apache.maven.plugin.PluginManager.installPlugin(PluginManager.jav
a:909)
at org.apache.maven.plugin.PluginManager.installPlugin(PluginManager.jav
a:878)
at org.apache.maven.plugin.PluginManager.processDependencies(PluginManag
er.java:458)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
658)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:486)
at org.apache.maven.cli.App.main(App.java:1230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
$
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
— Nested Exception —
java.lang.NullPointerException
at java.io.File.<init>(File.java:180)
at org.apache.maven.MavenUtils.makeAbsolutePath(MavenUtils.java:826)
at org.apache.maven.project.Project.resolveDirectory(Project.java:981)
at org.apache.maven.project.Project.resolveDirectories(Project.java:867)
at org.apache.maven.project.Project.initialize(Project.java:547)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:125)
at org.apache.maven.plugin.JellyScriptHousing.getProject(JellyScriptHous
ing.java:105)
at org.apache.maven.plugin.PluginManager.installPlugin(PluginManager.jav
a:909)
at org.apache.maven.plugin.PluginManager.installPlugin(PluginManager.jav
a:878)
at org.apache.maven.plugin.PluginManager.processDependencies(PluginManag
er.java:458)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
658)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:486)
at org.apache.maven.cli.App.main(App.java:1230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Attachments
Issue Links
| This issue is duplicated by: | ||||
| MAVEN-1572 | Recursive loop in target |
|
|
|
PS: I guess the culprit is the following resource:
<resource>
<include>plugin.jelly</include>
<include>plugin.properties</include>
<include>project.properties</include>
<include>project.xml</include>
</resource>
It should be something like:
<resource>
<directory>${basedir}</directory>
<include>plugin.jelly</include>
<include>plugin.properties</include>
<include>project.properties</include>
<include>project.xml</include>
</resource>
I know the POM is wrong, but maven shouldn't fail with a NPE. It should either:
1.Give a proper exception displaying the bad XML
2.Print a warning message and assume ${basedir} - this option would be more backward compatible.