You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2008/08/01 21:43:26 UTC
[jira] Created: (MNG-3694) plugin parameters injecting
${project.compileSourceRoots} get uninterpolated source directories
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
[jira] Closed: (MNG-3694) plugin parameters injecting
${project.compileSourceRoots} get uninterpolated source directories
Posted by "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