On 11/06/2008, at 1:05 AM, John Casey wrote:
Since the project can change in legitimate ways during the course of a build - especially for forked executions, such as changing the build directories - that means that expressions used to configure subsequent plugin executions MUST be synchronized to the internal state of the project itself. This is problematic when we interpolate all of these expressions up front, since we lose the dynamism. So, I'm experimenting with interpolating the POM without the build section up front, then interpolating the build section for each plugin execution, and back-propagating the changes to that section into the original, uninterpolated Build instance for future plugin executions.
How important is the propagation of changes to this? This seems the more complex part of it.
WRT delayed evaluation of expressions - that makes sense to me. In fact, I think that is already the case for plugin configuration elements - they are just evaluated at execution time, right?
It's a little heavy, but I haven't been able to imagine any other way out of this without changing the APIs used to manipulate project data. In the longer term, I think that's the right way forward, but or 2.0.x I don't want to force a massive re-release party for the plugins.
I think I'm agreed WRT propagating model changes from plugins in the future.
At any rate, I'm planning to write it all up and submit it to the dev list once I have working code that people can look at. I'm currently 4 ITs short of that.
Cool. Let me know if you need any specific feedback. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
