[
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250782#action_250782
]
John Casey commented on MNG-4962:
---------------------------------
Thinking about this a little more, the root of this problem seems to be the
change from 2.x -> 3.x to stop creating hard references between a MavenProject
and it's parent MavenProject instance. In 2.2.1, the getParent() method made
sense, since we were materializing the whole project set before we
started...the philosophy was geared around the CLI and not long-running
processes. In 3.x, having MavenProject.getParent() doesn't make sense. In 3.x,
it requires storing a reference to the ProjectBuilder, which isn't a model
object, it's a component. Also, it separates the use of the ProjectBuilder from
the larger build context, what we're calling the reactor. The list of other
files available in the reactor - and the models, coordinates, etc. available
from those files - is lost to this ProjectBuilder usage.
Maybe it'd be better to require callers to @Require their own reference to the
ProjectBuilder and request the parent MavenProject instance through that,
rather than allowing MavenProject.getParent(). Although, this currently shares
some of the context issues, namely that the original reactor model cache seems
to be discarded once the projects are constructed the first time by
DefaultMaven.collectProjects()...
> 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
