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 2011/01/06 23:27:57 UTC
[jira] Created: (MNG-4962) release:prepare with reactor BOM
referenced from reactor parent POM results in child with unchanged parent
version
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.1, 3.0, 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
[jira] Commented: (MNG-4962) release:prepare with reactor BOM
referenced from reactor parent POM results in child with unchanged parent
version
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Updated: (MNG-4962) MavenProject.getParent fails to build
when parent POM, in reactor, references BOM also in reactor
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey updated MNG-4962:
----------------------------
Summary: MavenProject.getParent fails to build when parent POM, in reactor, references BOM also in reactor (was: release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version)
> 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
> 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
[jira] Commented: (MNG-4962) release:prepare with reactor BOM
referenced from reactor parent POM results in child with unchanged parent
version
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Closed: (MNG-4962) MavenProject.getParent fails to build
when parent POM, in reactor, references BOM also in reactor
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MNG-4962) release:prepare with reactor BOM
referenced from reactor parent POM results in child with unchanged parent
version
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ 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