plugin parameters injecting ${project.compileSourceRoots} get uninterpolated
source directories
-----------------------------------------------------------------------------------------------
Key: MNG-3694
URL: http://jira.codehaus.org/browse/MNG-3694
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.10
Reporter: John Casey
This is the cause of the javadoc plugin error in 2.0.10-RC4. It seems that the
project's compileSourceRoots list is injected into the plugin configuration
BEFORE the project's concrete state is calculated. This leads to uninterpolated
compileSourceRoots being injected.
At least, this appears to be the case.
To reproduce:
mvn -Dtest=foo integration-test -DfailIfNoTests=false
-Dinvoker.mavenOpts="-Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
-Dinvoker.test=MJAVADOC-172
{noformat}
brett_: reactor projects are not concrete
[10:42am] brett_: project itself is fine, reactorProjects are not
[10:42am] jdcasey_: any project references should be made concrete, I added
that in DefaultMavenProjectBuilder.calculateConcreteState(..)
[10:42am] jdcasey_: brett: does it only happen in @aggregator mode?
[10:44am] brett_: no
[10:44am] brett_: it has @execute phase, but not @aggregator
[10:44am] jdcasey_: hmm
[10:44am] brett_: but it's not project references as such
[10:44am] jdcasey_: brett: is it running as a report when this happens, or as a
mojo?
[10:44am] brett_: it's ${reactorProjects}
[10:44am] jdcasey_: oh?
[10:44am] jdcasey_: oh
[10:44am] brett_: as a mojo
[10:44am] jdcasey_: damn
[10:45am] jdcasey_: I guess I'll need to calculate concrete state for the whole
reactor each time? ugh. I mean...ugh.
[10:45am] jdcasey_: that'll be slow
[10:46am] brett_: wouldn't they be made concrete once after complete loading?
[10:47am] jdcasey_: brett_: if any of the information in the build section
changes as a result of plugin execution, those changes wouldn't be reflected in
subsequent plugin executions
[10:47am] jdcasey_: like outputDirectory, for one big example
[10:47am] jdcasey_: that's what started all this
[10:47am] jdcasey_: theoretically, we could probably leave the
compileSourceRoots alone, but instrumentors could need that to change as well
[10:48am] jdcasey_: for forking, you know?
[10:48am] brett_: yeah
[10:48am] jdcasey_: brett_: the problem in 2.0.9 is that our interpolation got
a little too good, and didn't leave enough for the
PluginParameterExpressionEvaluator
[10:48am] jdcasey_:
[10:48am] jdcasey_: tricky, to say the least
[10:49am] brett_: when is th eproject made concrete now?
[10:50am] jdcasey_: brett: just before plugin execution, inside executeMojo(),
and then it's rolled back to dynamic state just after
[10:50am] jdcasey_: also, just before grabbing the report instance, and then
rolled back just before the report instance is passed back
[10:51am] jdcasey_: it actually doesn't seem to have imposed too great a
penalty so far, but this could be harder
[10:51am] jdcasey_: not sure
[10:51am] jdcasey_: we really need to get this aggregation stuff figured
out...${reactorProjects} was always meant to be used with an aggregator, IIRC...
[10:52am] brett_: yeah - and it is an aggregator, just conditionally
[10:52am] jdcasey_: yup, I know
[10:52am] brett_: so maybe you could make them concrete on lookup from the
plugin parameter expression evaluator?
[10:53am] jdcasey_: brett_: the problem is, there's nothing stopping a mojo
from using ${session} and then pulling the reactor projects from there...
[10:53am] jdcasey_: hmm, maybe
[10:53am] brett_: right
[10:54am] brett_: maybe the reactor projects can be concerete copies?
[10:54am] brett_: since they will only be used before they are built
[10:54am] jdcasey_: so I'd need to watch ${project.*} and ${session.*} and make
the current project +refs concrete in the first case, and all projects concrete
in the second...
[10:55am] jdcasey_: then, after the mojo is executed and/or report instance is
passed back, restore dynamism for all reactor projects
[10:55am] brett_: I'd need to think it through, but they should be able to be
made concrete up front since the aggregator runs first and they only get
modified in their later builds
[10:56am] brett_: avoid messing with the lookup
[10:56am] jdcasey_: the lookup?
[10:56am] brett_: ppee
[10:56am] jdcasey_: hmm
[10:57am] brett_: think it over
[10:57am] brett_: night!
[10:57am] jdcasey_: the reactor projects list isn't filled with static
instances, though...and it won't run up front unless it declares @aggregator
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
