Hi everyone,
As I'm sure you've noticed from the discussion on this list and my
commit logs, I've been working to solve a problem between concrete
interpolation of the POM at project-construction time and the need to
update plugin configurations to reflect changing state in the project
instance as the build progresses. The full proposal is here:
http://docs.codehaus.org/display/MAVEN/Dynamic+POM+Build+Sections
And the relevant JIRAs are mainly:
- MNG-3530
- MNG-3355
though there are others that doubtless touch on this problem.
The upshot is that our approach of trying to interpolate the entire POM
into a concrete version of itself when the project instance is
constructed is misguided. We've always done this to some degree or
other, with build paths being a notably varying aspect of this in past
releases. The issues surrounding build paths have been mainly concerned
with the difficulty of handling the alignment of relative paths with the
project base directory prior to making these paths available as
interpolation values.
However, it's currently possible for any part of the POM to be modified
by a plugin. This is an obvious threat to the declarative nature of the
POM in some respects, since it seems intuitive that having
setArtifacts() and setDependencies() methods on the project class should
mean that a plugin can add these things legitimately. In reality, this
couldn't be a worse idea, since it affects Maven's ability to report and
manage these dependencies - not to mention the basic need to have a
dependency set that is static and expressed for your project - is
compromised by such an action.
So, it makes sense to say that at least part of the POM should be purely
declarative, and set in stone once the project instance is created. On
the other hand, in order to support necessary build-time functionality,
the build section must be free from this constraint. If the clover
plugin can't reset the project.build.directory,
project.build.outputDirectory, and so forth, how can it do its work
without polluting the main set of classes which will be included in the
project's output artifact?
Therefore, this proposal suggests the following: mask out the build
section of the POM from initial interpolation, with the exception of
plugin coordinates and extensions (this is necessary to allow Maven's
core components to formulate the build process properly). Then, before
each plugin executes, re-interpolate only this build section using
up-to-date information from the project information. Finally, in order
to accommodate modifications to the project's build section itself -
which is the whole point of this exercise, after all - back-propagate
changes to this section into the original, uninterpolated build section
for inclusion in future plugin executions.
The proposal above is detailed on the Maven wiki at the link above. The
wiki page also includes links to relevant MNG issues, and the location
of the feature branch I've already modified to perform in exactly the
way I've mentioned. All tests are passing on this branch, so I'd like to
get input from other developers on this and hopefully get it merged back
to the main 2.0.x branch for inclusion in 2.0.10 before it goes stale.
Let me know what you think.
-john
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
