jgitver packaging in submodules

[nbn]

Issue

version:1.3.0

usage context: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)

Problem description:

• When using jgitver on a multimodule project it fails to package the correct version in submodules.

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:

mvn archetype:generate -B \
  -DarchetypeCatalog=internal \
  -DarchetypeGroupId=org.apache.maven.archetypes \
  -DarchetypeArtifactId=maven-archetype-quickstart \
  -DarchetypeVersion=1.1 \
  -DgroupId=fr.brouillard.jgitver.demos \
  -DartifactId=demo1 \
  -Dpackage=fr.brouillard.jgitver.demos \
  -Dversion=0

cd demo1

git init
git add .
git commit -m "inital commit"  

// Create extensions.xml file

mvn package

jar xvf target/demo1-0.0.0-SNAPSHOT.jar META-INF/maven/fr.brouillard.jgitver.demos/demo1/pom.xml
head META-INF/maven/fr.brouillard.jgitver.demos/demo1/pom.xml
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>fr.brouillard.jgitver.demos</groupId>
  <artifactId>demo1</artifactId>
  **<version>0.0.0-SNAPSHOT</version>**
  <name>demo1</name>
  <url>http://maven.apache.org</url>
  <properties>

mkdir demo1
mv src demo1
mv pom.xml demo1

**create new pom.xml:**
  <?xml version="1.0" encoding="UTF-8" standalone="no"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

  <groupId>fr.brouillard.jgitver.demos</groupId>
  <artifactId>demo1-parent</artifactId>
  <version>0</version>
    <packaging>pom</packaging>

    <modules>
        <module>demo1</module>
    </modules>
</project>  

mvn package

[INFO] no suitable configuration file found, using defaults
[INFO] Scanning for projects...
[INFO] Using jgitver-maven-plugin [1.3.0] (sha1: ef8eec9f820d662e63a84f1210c377183e450cbd)
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO]     fr.brouillard.jgitver.demos::demo1-parent::0 -> 0.0.0-SNAPSHOT
[INFO]     fr.brouillard.jgitver.demos::demo1::0 -> 0.0.0-SNAPSHOT

jar xvf demo1/target/demo1-0.0.0-SNAPSHOT.jar  META-INF/maven/fr.brouillard.jgitver.demos/demo1/pom.xml
head  META-INF/maven/fr.brouillard.jgitver.demos/demo1/pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>fr.brouillard.jgitver.demos</groupId>
  <artifactId>demo1</artifactId>
  **<version>0</version>**
  <packaging>jar</packaging>

  <name>demo1</name>

[McFoggy]

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:

• parent:1.0
  • child1:2.0 (with or without any relationship with parent)
  • child2:X.Y (with or without any relationship with parent)

IMO this is not the goal of multi-modules and denotes a bad usage of maven.

[nbn]

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.

[McFoggy]

never thought of such use cases. I'll look at it.

[McFoggy]

@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.

[nbn]

Thanks for taking the time to look at this case. I will try it out.

[athlan]

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) @

[McFoggy]

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.