Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-3694

plugin parameters injecting ${project.compileSourceRoots} get uninterpolated source directories

    XMLWordPrintableJSON

Details

    Description

      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

      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
      

      Attachments

        Issue Links

          Activity

            People

              jdcasey John Dennis Casey
              jdcasey John Dennis Casey
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: