Option to ignore plugin versions in pom.xml without need for Rules.xml

[garretwilson]

#258 requested the ability to allow <ignoreVersions> or its equivalent to be specified in the POM, like most other plugins, rather than in some separate, external rules file which is not inherited by the POM. #258 implemented a new exclusion system in the POM, but the implementation did not apply to the display-plugin-updates goal; this ticket is to add that functionality.

[jarmoniuk]

Sorry, I believe I misunderstood you in the beginning. The other ticket implemented a presentation filter of the listed dependency updates.

What I'm going to do now is create an alternative for providing a ruleset in the rules.xml file, via -D properties or configuration entries in the pom. This will be available (almost) universally.

[slawekjaranowski]

I'm starting think, that we implements the same things in duple place ...

I would do an exercise - add parameters with type RuleSet together with rulesUri.
We can use feature of mapping complex object of Maven:
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Complex_Objects

When DefaultVersionsHelper will receive filled object simply can use it instead of load one from uri.

[jarmoniuk]

Excellent idea. Will be slightly more difficult to unit test (unless I create a Builder).

[garretwilson]

Sorry, I believe I misunderstood you in the beginning. The other ticket implemented a presentation filter of the listed dependency updates.

First of all, sorry for the initial grumpy response earlier. I woke up expecting this to finally work and was hit with bad news in my inbox first thing in the morning. 😬

I think there will be less misunderstanding if we first clarify the use case before compiling a long list of features.

Use case: we want all of our applications, simply by inheriting from a common parent POM, with no further configuration, to be able to check, using a single command, whether any of their dependencies or plugins have a later release version (i.e. not release candidate, not milestone, etc.) available.

Also see my Versions Maven Plugin rules that are inheritable question on Stack Overflow.

What I'm going to do now is create an alternative for providing a ruleset in the rules.xml file, via -D properties or configuration entries in the pom.

That's what I thought this #258 was for! 😅

If the original Rules.xml did not cover plugin versions, then part of the misunderstanding was mine. I honestly didn't research it too much after it became obvious that it wasn't inheritable.

[garretwilson]

And I want to clarify one thing: if the dependency org.example:foo-bar:1.0.0 has org.example:foo-bar:2.0.0 available as well as org.example:foo-bar:3.0.0-M1, then if I add an exclude filter for *-M*, the Versions Maven Plugin should still show org.example:foo-bar:2.0.0. It should not show nothing because the newer version org.example:foo-bar:3.0.0-M1 has been filtered out. It should show the highest greater version that does not match an exclude.

Does that make sense? Perhaps that was already understood, but I wanted to mention it since there seems to have been a bit of confusion on some points.

[jarmoniuk]

First of all, sorry for the initial grumpy response earlier. I woke up expecting this to finally work and was hit with bad news in my inbox first thing in the morning. 😬

No worries. 😅

And I want to clarify one thing: if the dependency org.example:foo-bar:1.0.0 has org.example:foo-bar:2.0.0 available as well as org.example:foo-bar:3.0.0-M1, then if I add an exclude filter for -M, the Versions Maven Plugin should still show org.example:foo-bar:2.0.0. It should not show nothing because the newer version org.example:foo-bar:3.0.0-M1 has been filtered out. It should show the highest greater version that does not match an exclude.

Does that make sense? Perhaps that was already understood, but I wanted to mention it since there seems to have been a bit of confusion on some points.

Yes, that's what I'm working on right now, more or less.

By the way, I think you could probably be able to generate the rules.xml file with the resource plugin and then use the existing option with the version plugin to feed the file to it.

I'm gonna try it out myself just to check the idea.

https://stackoverflow.com/a/4389160

[jarmoniuk]

@garretwilson here's an example of how you can do that:

Provided you have a directory called rules-test in your project containing the rules template file:

<ruleset comparisonMethod="maven"
         xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0
         https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <ignoreVersions>
        <ignoreVersion type="regex">${ignoredVersions}</ignoreVersion>
    </ignoreVersions>
</ruleset>

Then, in your main project, create the following profile:

<profile>
  <id>rules-test</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>3.3.0</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>copy-resources</goal>
            </goals>
            <configuration>
              <resources>
                <resource>
                  <directory>rules-test</directory>
                  <filtering>true</filtering>
                </resource>
              </resources>
              <outputDirectory>${project.basedir}</outputDirectory>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>versions-maven-plugin</artifactId>
        <version>2.12.0</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>display-dependency-updates</goal>
            </goals>
            <configuration>
              <rulesUri>file://${project.basedir}/compiled-rules.xml</rulesUri>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

If you then execute the following Maven target:

mvn -P rules-test "-DignoredVersions=.*-(M\d*|.*-SNAPSHOT)" clean validate

then you will get a dependencies report using the filter in the -DignoredVersiosn argument (filtering out both *-M* and *-SNAPSHOT).

[garretwilson]

I am really not understanding why we simply can't put the rules in the POM (like they should have been in the first place) instead of in an external Rules.xml. I'm really not getting it. Why does it have to be complicated?

[Stephan202]

☝️ supporting the rule-2.0.0.xsd format inside a pom.xml plugin configuration element would indeed be preferred:

1. It enables easy migration.
2. It ensures that the new feature provides on-par functionality. (For example, IIUC Fixes #318 includes/excludes for dependencies #602 does not support regexes, which is quite a serious limitation).

It is my understanding that #602 supports only the versions:display-dependency-updates goal, while this issue asks for support of the versions:display-plugin-updates goal. I think that next to those two there should also be support for versions:display-property-updates. (All three support rulesUri.)

[jarmoniuk]

@slawekjaranowski:

would do an exercise - add parameters with type RuleSet together with rulesUri.
We can use feature of mapping complex object of Maven:
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Complex_Objects

When DefaultVersionsHelper will receive filled object simply can use it instead of load one from uri.

This seems to be working fine so far, passing the rulesets in the pom.xml:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>versions-maven-plugin</artifactId>
  <goals>
    <goal>display-dependency-updates</goal>
  </goals>
  <configuration>
    <ruleSet>
      <ignoreVersions>
        <ignoreVersion>
          <type>regex</type>
          <version>.+-SNAPSHOT</version>
        </ignoreVersion>
        <ignoreVersion>
          <type>regex</type>
          <version>.+-M\d+</version>
        </ignoreVersion>
        <ignoreVersion>
          <version>1.0.0</version>
        </ignoreVersion>
      </ignoreVersions>
    </ruleSet>
  </configuration>
</plugin>

Not so easy with the -D properties, therefore I'm thinking of creating an alternative parameter where one would be able to pass the comma-separated ignored versions only; I've already implemented that as well...

@Stephan202

It is my understanding that #602 supports only the versions:display-dependency-updates goal, while this issue asks for support of the versions:display-plugin-updates goal. I think that next to those two there should also be support for versions:display-property-updates. (All three support rulesUri.)

Not really; I was also confused. However, the goal here is to implement filtering on versions to consider for updates whereas that previous ticket (that is, what's already been implemented) is only a presentation filter -- intended to reduce clutter if one's only interested in a select set of dependencies.

This update will however be quite broad as rules support is in almost every mojo of this plugin, and we only need to allow passing them via another means.

[jarmoniuk]

For the command line parameter, should we use regexes or wildcards? What would you guys prefer?

[garretwilson]

For the command line parameter, should we use regexes or wildcards? What would you guys prefer?

Command-line parameter?

This simple request keeps getting made more complicated.

If you want to create some extra command-line parameter, which wasn't even part of the original request, I think it should go into a separate ticket so as not to confuse things.

[Stephan202]

This seems to be working fine so far, passing the rulesets in the pom.xml:

To be sure that I understand correctly: this <ruleSet> config is something you're currently working on? That's awesome! 💪

For the command line parameter, should we use regexes or wildcards? What would you guys prefer?

Not sure I'd use this feature, but in general I favour regexes in non-performance critical code (such as this plugin), since they're more expressive than wildcards.

[jarmoniuk]

Thanks for the input, I appreciate it.

[jarmoniuk]

The bulk of work here is going to be committed on test coverage, since the enhancement will be present in almost all mojos. The workload with the implementation of the feature itself is not that large.

So far, display-plugin-updates, display-property-updates, display-dependency-updates appear to work fine. Still working on coverage...

[jarmoniuk]

Implemented, hopefully it gets merged into the next release.