[
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4962.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Fixed in [r1070242|http://svn.apache.org/viewvc?view=revision&revision=1070242].
> MavenProject.getParent fails to build when parent POM, in reactor, references
> BOM also in reactor
> -------------------------------------------------------------------------------------------------
>
> 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
> Assignee: Benjamin Bentmann
> Fix For: 3.0.3
>
> 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
