Hi John,
I haven't looked at the code, but angling at it purely from the
proposal... it does make sense - the problem in the related issues is
forking lifecycles. In general, under the current structure, keeping
the pre-interpolated model and applying that after forking would make
sense. This solution effectively ensures that.
That said, this solution does sound a bit heavy handed. Even though we
have a bunch of ITs, something about this feels like it might break
something else. Do you have any thoughts on areas of risk outside what
the ITs already cover?
Cheers,
Brett
On 12/06/2008, at 2:17 AM, John Casey wrote:
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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
