Maven enforcer tries to enforce version management

[delanym]

I add to .mvn/extensions.xml

  <extension>
    <groupId>me.qoomon</groupId>
    <artifactId>maven-git-versioning-extension</artifactId>
    <version>7.1.2</version>
  </extension>

When I run mvn validate -N I get

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequirePluginVersions failed with message:
Some plugins are missing valid versions or depend on Maven 3.8.4 defaults: (LATEST RELEASE SNAPSHOT are not allowed)
me.qoomon:maven-git-versioning-extension.       The version currently in use is 7.1.2 via super POM or default lifecycle bindings

Because maven-enforcer-plugin includes enforce-managed-deps-rule:1.3 configured like so

                <requireManagedDeps implementation="org.commonjava.maven.enforcer.rule.EnforceManagedDepsRule">
                  <checkProfiles>true</checkProfiles>
                  <failOnViolation>true</failOnViolation>
                </requireManagedDeps>

I don't have this problem with my other extensions.

[qoomon]

Hi, thanks for reporting this behaviour. Could you provide a minimal project to reproduce this bug?

[qoomon]

I can't reproduce the warning.

My setup

• Apache Maven 3.8.4
• maven-git-versioning-extension 7.3.0
• maven-enforcer-plugin 3.0.0
  • enforce-managed-deps-rule 1.3

• pom file:

  <?xml version="1.0" encoding="UTF-8"?>
  <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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  
    <modelVersion>4.0.0</modelVersion>
  
    <groupId>test</groupId>
    <artifactId>test-artifact</artifactId>
    <version>0.0.0-SNAPSHOT</version>
  
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-enforcer-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <id>no-managed-deps</id>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <configuration>
                            <rules>
                                <requireManagedDeps implementation="org.commonjava.maven.enforcer.rule.EnforceManagedDepsRule">
                                    <checkProfiles>true</checkProfiles>
                                    <failOnViolation>true</failOnViolation>
                                </requireManagedDeps>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupId>org.commonjava.maven.enforcer</groupId>
                        <artifactId>enforce-managed-deps-rule</artifactId>
                        <version>1.3</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
  
  </project>

• extension file

  <extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 https://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
    <extension>
        <groupId>me.qoomon</groupId>
        <artifactId>maven-git-versioning-extension</artifactId>
        <version>7.3.0</version>
    </extension>
  </extensions>

• extension config file

  <configuration xmlns="https://github.com/qoomon/maven-git-versioning-extension"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="https://github.com/qoomon/maven-git-versioning-extension https://qoomon.github.io/maven-git-versioning-extension/configuration-7.0.0.xsd">
    <refs>
        <ref type="branch">
            <pattern>.*</pattern>
            <version>${ref}-SNAPSHOT</version>
        </ref>
    </refs>
  
  </configuration>

[delanym]

@qoomon https://github.com/delanym/maven-git-versioning-extension-test

[qoomon]

I"m able to reproduce the bug, thanks a lot. I found the root cause already, however I still try to figuring out how to work around that.

[delanym]

Ok cool. BTW we've been using https://github.com/pascalgn/properties-maven-extension for a long time. Its really simple and did what we needed. But the author is not getting around to the issues I've logged - I haven't the skills to fix them myself. One of them is critical for our workflow so I'm contemplating using this extension instead.

Is it possible for the extension to

• not write intermediate pom files to disk
• provide the git.dir.worktree property
• set the version to the output of git describe --abbrev=0

We're using CI-friendly properties https://maven.apache.org/maven-ci-friendly.html Since the properties-maven-extension doesn't give the correct tag I'm forced to set the revision myself with -Drevision=2.2.14 All I need this extension to do is set the revision according to git describe --abbrev=0

[qoomon]

I have two simple workarounds so far:

• set enforcer face to <phase>initialize</phase>
• or exclude extension plugin

  <requirePluginVersions>
    <unCheckedPluginList>me.qoomon:maven-git-versioning-extension</unCheckedPluginList>
  </requirePluginVersions>

[qoomon]

I think I was able to fix it. The fix is already on master branch. Feel free to test it. I'll release a fixed version tomorrow.

[qoomon]

@delanym

Is it possible for the extension to

• not write intermediate pom files to disk

yes and no :) An .git-versioned.pom.xml will be created always. The original pom.xml will be updated only, if configured within plugin config file or if the command line parameter is set.

• provide the git.dir.worktree property

currently thats not supported, however I could add this feature quite easily.

• set the version to the output of git describe --abbrev=0

yes see ${describe} in README

[delanym]

@qoomon having git.dir.worktree would undepend me on the properties-maven-extension so that would be great.

Creating .git-versioned.pom.xml follows the same approach as flatten-maven-plugin. But this is overkill to write out 500+ files when only a single line changes. We're stuck building on NTFS disk and sometimes have lock file issues, so the less IO the better. As an extension, the poms are written out for ALL projects, even when I just want to build one project with -pl switch, or when gitflow-incremental-builder extension limits the projects. This also comes with an extra 1500+ lines of logs. Can these be turned off?

[qoomon]

Out of curiosity, what do you need git.worktree for?

[delanym]

@qoomon there are a couple of ways to figure out the root Maven directory but none as reliable as asking git. There was a discussion about this on the users mailing list last year. For example, I configure the depgraph-maven-plugin with <customStyleConfiguration>${git.dir.worktree}/depgraph.json</customStyleConfiguration>

[qoomon]

i just added git.worktree project property at master branch

[qoomon]

Regarding the generation of .git-versioned-pom.xml , I'll need to do some more testing. I"ll keep you posted.

[qoomon]

I'm not sure what is the best way to implement not writing git versioned pom file right away. What do you think about following ideas and questions?

• What would consider the best phase to write git versioned pom file? process-resources, prepare-package, ... ?
• What about using VALIDATE as default execution phase and add an option to overwrite phase?
• My problem is I don't know what effect it could have on other plugins, if the loaded project model points to the original pom.xml or to a non existing pom.xml if I change the pom location in the model without creating the pom right away.

[delanym]

What I don't understand from the start is why you're calling this an extension when its actually a plugin?

Currently I use properties-maven-extension to set a property that determines the version number of projects before the poms are even parsed. It greatly simplifies the issue. Of course I have to use CI-friendly properties to achieve this, but Im quite happy to.

FYI I run enforcer and sortpom plugin in validate, followed by flatten in initialize (although this could come later).

[qoomon]

The plugin mechanism ist only needed to postpone set new pom location. This is needed to make maven plugins work like mvn versions:set -DnewVersion=1.0.0, otherwise this change would be written to the git version pom file. The reason I need to set new pom location at all, is that otherwise the unmodified pom would be part of a maven release (mvn deploy)

[JWT007]

Hi @qoomon, just jumping in here :)

I am using 9.3.1 and the only way I have to get around the enforcer problem is still the "unCheckedPluginList" option - but that works fine for me ... just need to remember to add it to each project.

@delanym regarding extension vs. plugin - see: https://maven.apache.org/guides/mini/guide-using-extensions.html

_"Extensions are a way to add classes to Core Classloader. This is necessary for adjusting Maven in a way that affects more than just one plug-in."_

By the way you can limit output to the logger if you change the log-level for the extension: ie. in your top-level project add a ".mvn/jvm.config" and add the following line to it (which will change from 'info' to 'error')

-Dorg.slf4j.simpleLogger.log.me.qoomon.maven.gitversioning.GitVersioningModelProcessor=error

But then you really see nothing if no errors pop...this will be it.

[03:48:25.758+0100] [INFO] --- maven-git-versioning-extension:9.3.1:git-versioning (git-versioning) @ foobar ---

That being said the info output is very useful to see that your configured pattern rules are working correctly...otherwise you might be searching for a while when something misbehaves :)

[03:50:25.437+0100] [INFO] --- me.qoomon:maven-git-versioning-extension:9.3.1 [core extension] ----
[03:50:28.113+0100] [INFO] matching ref: BRANCH - master
[03:50:28.113+0100] [INFO] ref configuration: BRANCH - pattern: master
[03:50:28.114+0100] [INFO]   version: ${version}
[03:50:28.126+0100] [INFO] 
[03:50:28.127+0100] [INFO] foobar
[03:50:28.130+0100] [INFO] set version to 1.1.x-SNAPSHOT

As far as I can tell, a separate file must be written to disk for each the main project and any sub-modules because:

• it needs to be read by a MavenXpp3Reader to get the modified model
• the extension sets this model file as the new source so that the maven-install-plugin can install it instead.
• other plugins with similar functionality work the same way (ie. flatten-maven-plugin) (Correct me if I am wrong @qoomon :) I have just been deep-diving on extensions myself this week)

I think validate is your best phase...because everything after that relies on the modified model? (ie. filtering resources and replacing ${project.version}). You need to replace the effective model early. I think if defined in the .mvn/extensions.xml the phases don't really apply and the early-loading hooks into the lifecycle-listener after the MavenSession is started and before any other phases are run???

Either way wouldn't this be a feature request for the maven-enforcer-plugin on the check to add an option to ignore extensions? Just by chance I had created this exact ticket last week :P:

https://issues.apache.org/jira/browse/MENFORCER-436

[qoomon]

maybe it is possible to add me.qoomon:maven-git-versioning-extension to unCheckedPluginList automatically by the extension.

[JWT007]

is it loaded by that point? or it might not be in the plugin list at all... it would require a dependency on the enforcer plugin wouldn't it? it is the question if you need to try to deal with a "bug" from another plugin? :)

[qoomon]

feel free to try version 9.3.2, it should add plugin to unCheckedPluginList automatically.