Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.0, 3.0.1, 3.0.2
-
None
Description
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.
Attachments
Attachments
Issue Links
- is related to
-
-
- Closed
-