[
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250785#action_250785
]
John Casey commented on MNG-4962:
---------------------------------
It would be nice to have the option to specify a durable "working memory" of
sorts for Maven, with the default for long-running callers being an on-demand
cache instead. This might give workflow executions like release:prepare or any
normal build the opportunity to track things like BOMs present and used in the
same reactor, while still allowing non-workflow usages like m2eclipse to
function without too much overhead or risk of staleness.
> release:prepare with reactor BOM referenced from reactor parent POM results
> in child with unchanged parent version
> ------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4962
> URL: http://jira.codehaus.org/browse/MNG-4962
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Reactor and workspace
> Affects Versions: 3.0, 3.0.1, 3.0.2
> Reporter: John Casey
> Attachments: release-parent-adjustment.zip, test.git.zip
>
>
> I'm attaching a sample project that displays the behavior.
> Essentially, the project structure is a multimodule project with two levels
> of parent POMs, not unlike the structure found in maven-scm or similar. There
> is also a top-level submodule that is just a Bill-of-Materials POM, named -
> 'bom'. The second-level parent POM, named 'children' imports 'bom', and is
> inherited by the 'child1' submodule.
> When release:prepare is run, the POMs are transformed on disk, it seems to
> trigger a re-resolution of the 'child1' parent reference - the
> MavenProject.getParent() call triggers the ProjectBuilder.build(...) to
> retrieve the 'children' POM. When this happens, the process of building the
> 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this
> point there is no reactor cache at all, much less one that contains the
> proper coordinate for the transformed BOM. This means the
> project-construction for 'children' fails, and the parent reference in the
> 'child1' MavenProject instance is null...which means the release plugin's
> check of MavenProject.hasParent() returns false, and the <parent/> reference
> doesn't get updated.
> I haven't dug deeper than this, so I'm not sure how the reactor cache is
> lost, or how it was ever preserved so that the MavenProject.getParent() call
> could succeed under normal circumstances.
> I know that the <parent/> update works in this scenario when using Maven
> 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing
> it's taking advantage of a higher-level cache within the MavenProjectBuilder
> itself to avoid losing track of the parents. I also know that it eagerly
> builds/resolves/associates parent MavenProject instances, so maybe that has
> something to do with it.
--
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
