maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Casey (JIRA)" <>
Subject [jira] Closed: (MNG-3694) plugin parameters injecting ${project.compileSourceRoots} get uninterpolated source directories
Date Fri, 01 Aug 2008 20:42:26 GMT


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:
>             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:
For more information on JIRA, see:


View raw message