Open nbn opened 5 years ago
your sub project should define a parent relation ; please see https://github.com/jgitver/jgitver-samples/tree/master/multi-module.
In standard maven you are also able to define:
IMO this is not the goal of multi-modules and denotes a bad usage of maven.
Fair enough, however, the reason for reporting this is that in my specific case, the actual submodule is based on a spring boot parent, which makes it impossible to provide another parent relationship. Secondly, jgitver actually change the version of the submodule without any non-parent warning, and gladly use the correct version through the remaining operations. Everything else seems to work but the enclosed/attached pom. I thought it might be an interesting usecase, given that it is partially successful.
never thought of such use cases. I'll look at it.
@nbm after I have worked on #102, a workaround exists for your case
in your sub project add an execution of flatten-maven-plugin like the following:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>jgitver-flatten-pom</id>
<phase>validate</phase>
<goals>
<goal>flatten</goal>
</goals>
<configuration>
<flattenMode>defaults</flattenMode>
<updatePomFile>true</updatePomFile>
<pomElements>
<dependencyManagement>keep</dependencyManagement>
<build>resolve</build>
<ciManagement>resolve</ciManagement>
<contributors>resolve</contributors>
<dependencies>resolve</dependencies>
<description>resolve</description>
<developers>resolve</developers>
<distributionManagement>resolve</distributionManagement>
<inceptionYear>resolve</inceptionYear>
<issueManagement>resolve</issueManagement>
<mailingLists>resolve</mailingLists>
<modules>resolve</modules>
<name>resolve</name>
<organization>resolve</organization>
<parent>resolve</parent>
<pluginManagement>resolve</pluginManagement>
<pluginRepositories>resolve</pluginRepositories>
<prerequisites>resolve</prerequisites>
<profiles>resolve</profiles>
<properties>resolve</properties>
<reporting>resolve</reporting>
<repositories>resolve</repositories>
<scm>resolve</scm>
<url>resolve</url>
<version>resolve</version>
</pomElements>
</configuration>
</execution>
</executions>
</plugin>
In a next future I plan to bring the additions from e851ee7c3e081ab186349cee41fe5c027b86a6c9 (provided for #102) as defaults in the jgitver-maven-plugin.
Today, using latest version (1.4.4 at the time of writing) even if you activate the new flatten-maven-plugin via -Djgitver.flatten=true
; still your use case will not be covered.
Thanks for taking the time to look at this case. I will try it out.
It still does not work with 1.5.1
My use case: I have Bill of Materials maven submodule with version 0.0.0-SNAPSHOT. It's metioned in aggregated pom (top-level one) as module, but does not reference parent. Project dependencies defined as ${project.version}
. However, they're uploaded to Nexus as is, without flattering versions, so they still point to 0.0.0-SNAPSHOT.
Jgitver in its blogs tells that it discovers BOM project and changes version for it, but from some reason, poms are uploaded with 0.0.0-SNAPSHOT. Rest of modules are okay.
It looks like jgitver traverses by parent-definitions, not by module definitions while changing versions.
Basically for BOM project I cannot see execution of (as per for rest modules):
[INFO] --- flatten-maven-plugin:1.2.2:flatten (jgitver-flatten-pom) @
It looks like jgitver traverses by parent-definitions, not by module definitions while changing versions.
indeed, this is still a change that needs to be fixed.
Issue
version:1.3.0
usage context: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
Problem description:
Steps to reproduce:
1) Create archetype demo1 project as from the documentation 2) Verify the correct version in target/demo1....jar:/META-INF/....pom.xml 3) Move demo1 to a sub directory and create a new parent module 4) Retry the verification in demo1/target/demo1...jar:/META-INF/...pom.xml
Example below: