otherDeploymentBranchPattern doesn't work with multi-module builds and ${project.version}

[robth]

When a branch matches otherDeploymentBranchPattern, the normalized branch name will be appended to the POM version. Under the hood, the plugin uses project.setVersion() to set the version. It does not change the POM.

For multi-module builds and builds that use ${project.version}, this causes problems since parent versions and ${project.version} are not set to the correct version (i.e. the version including the branch name).

For example, a module referencing its parent:

<parent>
  <groupId>test</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0-SNAPSHOT</version> <!-- Note that the branch name is missing -->
</parent>

For example, a (parent) POM with dependency management of its modules:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>test</groupId>
      <artifactId>module1</artifactId>
      <version>${project.version}</version> <!-- Note that project.version won't contain the branch name -->
    </dependency>
  </dependencies>
</dependencyManagement>

I don't see a simple way to solve this, or am I missing something?
The only solution I see is to change the POM file. That can be done either by the user (see #83), or automatically by the plugin.

What do you think?

[bvarner]

Yikes.

I've tried to avoid imposing persistent POM manipulations as a consequence of building projects.
I'd like to treat the POM as an immutable file, and I'd like the build tools to be able to do that.

Any chance you'd be willing to create a test case that clearly duplicates this (and obviously fails during the integration tests)?

[robth]

Yes, no problem, I will write a test case and offer a PR.

[robth]

@bvarner How would you like to continue with this issue? It's blocking feature branch deployment. My proposal is to just let enforce-versions check whether the branch name is part of the artifact version. Then it's up to the user to set the correct version. It's not ideal, but it should work. What do you think?

[bvarner]

Sorry for the ridiculously slow response -- I may need to draft another maintainer. :-)

So you'd have enforce-versions check if the branch name is part of the artifact version and then... do what? I'm not sure I follow here.

I'm currently working on a project where we're just talking about pushing feature branch artifacts to the snapshots repo so that other projects can use poc's deployed there. Our plan at this point was to have that dependency managed by the devs, in the pom, with the expectation that there would have to be a non-snapshot release of that feature before the dependent project could continue.

We've so far avoided having a parent pom -- although that's been part of our discussions as well.

[bvarner]

I ran into a similar case the other day, using the quarkus maven plugin to build a quarkus project.

Since then, I've been mulling over what to do.

Currently, the version setting happens in the retarget deploy mojo -- very very late in the build cycle.

The version manipulation should probably happen in an extension.
In this case, we could manipulate the project models in memory before any goal execution begins.

This would include all the projects being built as part of the current session.
I think this would actually make the intended features work as expected.

[bvarner]

So...

I've been playing around with this idea in a branch, and what I come down to is:

All the projects and their metadata can be updated before the reactor actually kicks off -- if you manipulate versions in an extension. This allows parents, inter-dependencies, plugins, and multi-module projects etc. to all work quite well.

The problem then becomes with the resultant pom that gets attached / deployed. It's not reflecting those changes, because it's based upon the File contents of the originating pom.

The extension manipulations I've been doing are all on the in-memory Project model.... which is nice, in that it's transient and leaves the original POM the reactor was built from in place and unaltered.

What I'm thinking about: is having the RetargetDeployMojo continue to set the snapshot repository, but also write the massaged copy of the project POM to the target directory, then set that as the active pom file on the in-memory project. This should make 'everything just work'.

Other outside projects could use the version as a dependency.
Multi-modules and parents could manage versions explicitly.

The only thing I haven't tried out locally yet is the writing of the massaged pom. I'll get that to this week, if things allow.

[bvarner]

@robth, I've pushed an in-progress branch that's currently missing the automated test cases, but if you have any interest in testing this out, here's where I'm currently at:

https://github.com/egineering-llc/gitflow-helper-maven-plugin/tree/feature/other-branch-reversioning-extension

It looks like this works pretty well.

[glimmerveen]

@bvarner as I am interested in this as well I had a look at the branch and tried it out myself. It looks pretty good IMO. I have also seen it play nice with other maven plugins that use/rely on the project version, and correctly 'see' the re-written version.

Some remarks:

• The 'massaged' pom is put next to the regular pom.xml file. Personally I am not too keen on plugins creating files outside the build directory. Would it be possible to create this pom file in the build directory (target folder)?
• When looking at a multi-module project, I noticed a small difference between my pom.xml file and the massaged pom.xml file. The former inherited the version from the parent declaration, whilst the latter would also include an explicit declaration of the version of the child as well. The end result (the version of the child) is the same, so I guess it is not an issue.

How close do you see this to being finished? Any aspects you'd like to see tested? I am willing to help anywhere I can!

[glimmerveen]

I have done some additional experiments and noticed that the re-written version is visible for plugins when they obtain that version from the injected MavenProject.
If the version is supplied to the plugin through its configuration as the property ${project.version}, then it is resolved to the original value.

For example see this use of the maven-antrun-plugin:

            <plugin>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <phase>process-classes</phase>
                        <configuration>
                            <propertyPrefix>mvn.</propertyPrefix>
                            <target>
                                <echo>${project.version}</echo>
                                <echo>${mvn.project.version}</echo>
                            </target>
                        </configuration>
                        <goals>
                            <goal>run</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Will result in:

[INFO] --- maven-antrun-plugin:3.0.0:run (default) @ child2 ---
[INFO] Executing tasks
[WARNING]      [echo] 1.0-SNAPSHOT
[WARNING]      [echo] 1.0-feature-test-SNAPSHOT
[INFO] Executed tasks

The ${project.version} returns the original project version value, whilst the ${mvn.project.version} returns the expected re-written project version value.

I noticed while debugging these from one of the Extensions's afterProjectRead callbacks, that the configuration of the maven-antrun-plugin already had the property project.version expanded to the original value of the project version.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <propertyPrefix>mvn.</propertyPrefix>
  <target>
    <echo>1.0-SNAPSHOT</echo>
    <echo>${mvn.project.version}</echo>
  </target>
</configuration>

That explains why ${mvn.project.version} expands to the expected (re-written) version, as that value is obtained by the maven-antrun-plugin from the MavenProject.

Note sure if this can be addressed or not, but is at least something to be aware of.

[glimmerveen]

After integration with Jenkins I got following warning from Jenkins' Maven probe:

[WARNING] [jenkins-event-spy] Unexpected Maven project file name 'pom-gitflow-massaged.xml', problems may occur

This probe is aware of the fact that Maven plugins could re-configure/alter the pom file and tries to find 'the right one'. In some cases it uses the alternative one, and in others it uses the original one.
To address this warning we could see if the Maven probe can be extended to include an specific branch for this plugin as well (it already has some hardcoded branches to deal with various other maven plugins), or the location and name of the massaged pom files should be made configurable.
The latter would have my preference, as it should allow the user to also relocate this generated file towards the target folder, for example towards target/gitflow/pom.xml. In that case the Maven probe should stay silent (as the path ends with /pom.xml) and the generated file would be in the target folder.
What do you think of this approach @bvarner ?

[glimmerveen]

I have a final observation and that is related to the use of profiles. It appears that if a pom contains a profile that is activated with a file (exists/missing), that the 'massaged' pom will contain the resolved absolute path rather than the path defined in the source pom file.
This may be an issue in Maven itself, as I think the MavenProject.getOriginalModel() should have returned a Model completely unresolved. I have posted a question on the Maven mailinglist to see if this is indeed an issue with Maven itself, or that the plugin needs to address.

[glimmerveen]

With regards to the massaged pom file containing resolved (absolute) paths for file-based profile activation: this is indeed an issue in Maven itself. There is a PR open at Maven (apache/maven#347) to solve this issue.