[
http://jira.codehaus.org/browse/MNG-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3694.
---------------------------
Assignee: John Casey
Resolution: Fixed
Fix Version/s: 2.0.10
fixed for RC5
> 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
> Assignee: John Casey
> Fix For: 2.0.10
>
>
> 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
