[
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250780#action_250780
]
John Casey commented on MNG-4962:
---------------------------------
Digging into this a bit further, it seems that
DefaultModelBuilder.importDependencyManagement(..) is called twice when running
release:prepare. The first time is as a result of the
DefaultMaven.collectProjects(..) execution, where the complete list of project
files is used to build up an effective reactor model cache.
The second time is a result of MavenProject.getParent(), which uses the
ProjectBuildingRequest stored in the MavenProject instance, and has no notion
of other models available in the reactor. It seems like this is a special
problem when it comes to loading import-scoped dependencies, since they have no
relative path attached to them. With no relative path to use in reconstructing
a reactor path, and no cached model for the BOM, parent POMs referencing BOMs
in the same reactor will fail to build.
Another symptom of this problem is that the failure to build the parent
MavenProject instance on-demand will be visible only in the great wash of
output that is the debug log-level. In other words, it will not prevent the
build from progressing, in spite of the fact that an explicit call has to be
made requesting this information in order to trigger the failure...which IMO by
default we should assume is critical to the build's progress. If this call is
made and the parent-project construction fails, the caller should be given the
opportunity to handle the exception.
> 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
