Hi all,
I'm having some problems with the maven-clover-plugin and generating
resources (in the generate-resources phase) into the appropriate
target directory. The clover plugin forks a lifecycle and modifies
the build finalName to include the classifier "-clover". I generate
a web.xml file (for a war, using xdoclet) using the webdoclet
configuration:
<webdoclet destDir="${project.build.directory}/$
{project.build.finalName}/WEB-INF">
...
</webdoclet>
This configuration is in a custom execution for the xdoclet plugin,
running in the generate-resources phase. It simply states to
generate some output in the destDir location (the particular output
isn't really important).
When the forked lifecycle executes, the project.build.finalName
property is not reflecting the forked lifecycle's value (i.e. it does
not include the -clover classifier). This causes the build to fail,
as the appropriate configuration files are not written for the war
plugin to package up a war.
This problem can also easily be seen by using the maven clover plugin
(to fork a lifecycle) and binding an ant-run task to the generate-
resources phase that simply echoes out the appropriate properties:
<execution>
<id>normal</id>
<phase>generate-resources</phase>
<configuration>
<tasks>
<echo message="${project.build.finalName}" />
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
This will print out the same finalName in the initial and forked
lifecycles, even though clover explicitly changes the finalName to
include the classifier.
My question is: am I doing something wrong, or does this look like a
bug in maven? I'm on the latest stable release of maven (2.0.4),
using maven-clover-plugin 2.3 and maven-war-plugin 2.0.1.
One additional piece of interesting (though maybe not relevant)
information is that help:effective-pom shows the interpolated value
of the variable ${project.build.finalName}, while it leaves other
variables (like ${project.build.directory}) in the uninterpreted
form. Is there a reason for this, and if so is it possible that
finalName has been erroneously marked somewhere as constant between
lifecycles?
Cheers,
Chris Tucker
