[jira] Closed: (MNG-3694) plugin parameters injecting ${project.compileSourceRoots} get uninterpolated source directories

["John Casey (JIRA)" <ji...@codehaus.org>]

     [ 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