Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
simdevmon opened this issue Feb 2, 2018 · 32 comments
Closed

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

simdevmon opened this issue Feb 2, 2018 · 32 comments

Comments

@simdevmon
Copy link

I think it would be convenient if I could specify versions to ignore directly in pom.xml under the configuration tag. Then I would not have the need to create an extra Rules.xml file, but could simply specify everything directly in the pom:

<ignoreVersions>
    <ignoreVersion type="regex">.*-beta.</ignoreVersion>
    <ignoreVersion type="regex">.*_ALPHA</ignoreVersion>
</ignoreVersions>
@johnou
Copy link

johnou commented Apr 20, 2018

This would also avoid the problem with multi-module projects and having to use the <rulesUri>file:///${session.executionRootDirectory}/versions-rules.xml</rulesUri> hack.

@svbrunov
Copy link

svbrunov commented Apr 10, 2020

Hi, everyone!

Completely agree with the previous authors.

The requested functionality is quite essential, so it would be great to have it.

Best regards,
Sergey Vyacheslavovich Brunov.

@svbrunov
Copy link

Dear maintainers,

Please, consider re-opening this GitHub issue.

Best regards,
Sergey Vyacheslavovich Brunov.

@slachiewicz slachiewicz reopened this Nov 13, 2021
@slachiewicz slachiewicz removed the Stale label Nov 13, 2021
@garretwilson
Copy link

garretwilson commented Jun 7, 2022

How can I vote for this? I have a bounty running on Stack Overflow to try to find a workaround. Most plugins don't make me create an entire separate project just to configure them and have their configurations be inherited in child projects. Why should this one be any different?

@garretwilson
Copy link

Could someone give an update on whether there is any thought of fixing this soon? We're about to release a new version of our POM and it would be good to know if this is at least scheduled tentatively or if there isn't any hope for it being addressed.

@andrzejj0
Copy link
Contributor

andrzejj0 commented Sep 5, 2022

It looks like a feature like this has recently been implemented by #369. Please see #318 where it's possible to provide inclusion and exclusion filters for determining which dependency patterns will be considered. Thanks to that, you can rule out patterns such as .*-beta. or .*_ALPHA, albeit not using regexp, but simple asterisk wildcards.

This will land in today's release (2.12.0). @slachiewicz

@garretwilson
Copy link

@ajarmoniuk , can you clarify? Are these inclusions and exclusions with wildcards something that I can put in the POM? (The examples at #369 only show JVM property usage on the command line.) I don't see this mentioned in the display-dependency-updates documentation.

@andrzejj0
Copy link
Contributor

andrzejj0 commented Sep 5, 2022

Hi @garretwilson, it's not in the docs yet because the version has not yet been released. 😄

You can use the arguments just like you'd use the properties. For instance, for the following configuration (no filtering):

<profile>
  <id>display-dependency-updates</id>
  <build>
    <plugins>
      <plugin>
        <groupId>${project.groupId}</groupId>
        <artifactId>${project.artifactId}</artifactId>
        <version>${project.version}</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>display-dependency-updates</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

You'd have the following updates listed:

--- versions-maven-plugin:2.12.0-SNAPSHOT:display-dependency-updates (default) @ versions-maven-plugin ---

[INFO] The following dependencies in Dependency Management have newer versions:
[INFO]   org.apache.maven:maven-plugin-api ............................. 3.2.5 -> 3.8.6
[INFO] 
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   org.apache.maven:maven-artifact ............................... 3.2.5 -> 3.8.6
[INFO]   org.apache.maven:maven-compat ................................. 3.2.5 -> 3.8.6
[INFO]   org.apache.maven:maven-core ................................... 3.2.5 -> 3.8.6
[INFO]   org.apache.maven:maven-model .................................. 3.2.5 -> 3.8.6
[INFO]   org.apache.maven:maven-plugin-api ............................. 3.2.5 -> 3.8.6
[INFO]   org.apache.maven:maven-settings ............................... 3.2.5 -> 3.8.6
[INFO]   org.apache.maven.doxia:doxia-core ......................... 1.11.1 -> 2.0.0-M3
[INFO]   org.apache.maven.doxia:doxia-sink-api ..................... 1.11.1 -> 2.0.0-M3
[INFO]   org.apache.maven.doxia:doxia-site-renderer ................ 1.11.1 -> 2.0.0-M3
[INFO]   org.apache.maven.reporting:maven-reporting-api ............. 3.1.1 -> 4.0.0-M2
[INFO]   org.apache.maven.reporting:maven-reporting-impl ............ 3.2.0 -> 4.0.0-M2
[INFO] 
[INFO] The following dependencies in pluginManagement of plugins have newer versions:
[INFO]   com.puppycrawl.tools:checkstyle ................................ 9.3 -> 10.3.3
[INFO] 
[INFO] The following dependencies in Plugin Dependencies have newer versions:
[INFO]   com.puppycrawl.tools:checkstyle ................................ 9.3 -> 10.3.3
[INFO] 
[INFO] ------------------------------------------------------------------------

Version 2.12.0 will introduce new arguments: dependencyIncluded, dependencyExcludes, dependencyManagementIncludes, dependencyManagementExcludes.

For the following config:

<profile>
  <id>display-dependency-updates</id>
  <build>
    <plugins>
      <plugin>
        <groupId>${project.groupId}</groupId>
        <artifactId>${project.artifactId}</artifactId>
        <version>${project.version}</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>display-dependency-updates</goal>
            </goals>
            <configuration>
              <dependencyIncludes>org.apache.maven.*:doxia*</dependencyIncludes>
              <dependencyManagementIncludes>com.puppy*:*</dependencyManagementIncludes>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

The output fill be filtered wrt dependencies and dependency management:

[INFO] --- versions-maven-plugin:2.12.0-SNAPSHOT:display-dependency-updates (default) @ versions-maven-plugin ---
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   org.apache.maven.doxia:doxia-core ......................... 1.11.1 -> 2.0.0-M3
[INFO]   org.apache.maven.doxia:doxia-sink-api ..................... 1.11.1 -> 2.0.0-M3
[INFO]   org.apache.maven.doxia:doxia-site-renderer ................ 1.11.1 -> 2.0.0-M3
[INFO] 
[INFO] The following dependencies in pluginManagement of plugins have newer versions:
[INFO]   com.puppycrawl.tools:checkstyle ................................ 9.3 -> 10.3.3
[INFO] 
[INFO] The following dependencies in Plugin Dependencies have newer versions:
[INFO]   com.puppycrawl.tools:checkstyle ................................ 9.3 -> 10.3.3

I don't know why plugins and pluginManagement sections have not got filtering, perhaps I'll add that (but I really doubt that will be available in today's release 😄 ).

@garretwilson
Copy link

Woohoo! @ajarmoniuk you don't know how excited I am to try this out.

I don't know why plugins and pluginManagement sections have not got filtering

Yeah that's the next thing I thought of to ask you. 😄 I think the dependencies section is the most important, but I'll bet we'll need them in the other sections too.

OK, I'm 🤞 waiting for the release!

@garretwilson
Copy link

garretwilson commented Sep 5, 2022

Your example wasn't quite clear as to my use case. So I would be able to ignore all newer milestone versions of all dependencies using something like this:

<configuration>
  <dependencyExcludes>*:*:*-M*</dependencyExcludes>
  <dependencyManagementExcludes>*:*:*-M*</dependencyManagementExcludes>
</configuration>

And after adding these exclusions, the plugin would no longer say that org.apache.maven.doxia:doxia-core had a newer version, as the newer version 2.0.0-M3 is a milestone matching the excludes. But if a version 1.11.2 came available, it would notify me of that.

Do I understand the usage correctly?

Because from the example you gave, it's not clear whether "exclude" means "don't check for any new versions for these excluded dependencies" (which is a different use case altogether and will not help me), or "don't display newer versions that match these excludes" (which is the the desired use case here).

@andrzejj0
Copy link
Contributor

andrzejj0 commented Sep 5, 2022

Yes, you seem to understand it correctly.

Well, it's quite complex actually.

Include means only show the dependencies satisfying the filter.
Exclude means show everything that is included (so, really everything if there's no include filter) except the ones matching the exclude filter.

Set<Dependency> onlyIncludes = includeDeps.retainingIn( dependencies );
Set<Dependency> filtered = excludeDeps.removingFrom( onlyIncludes );

andrzejj0 added a commit to andrzejj0/versions-maven-plugin that referenced this issue Sep 5, 2022
andrzejj0 added a commit to andrzejj0/versions-maven-plugin that referenced this issue Sep 5, 2022
@andrzejj0
Copy link
Contributor

So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.

andrzejj0 added a commit to andrzejj0/versions-maven-plugin that referenced this issue Sep 5, 2022
andrzejj0 added a commit to andrzejj0/versions-maven-plugin that referenced this issue Sep 5, 2022
andrzejj0 added a commit to andrzejj0/versions-maven-plugin that referenced this issue Sep 5, 2022
andrzejj0 added a commit to andrzejj0/versions-maven-plugin that referenced this issue Sep 5, 2022
@garretwilson
Copy link

So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.

@ajarmoniuk , do you happen to know if the plugin-related exclusion configuration made it into v2.12.0?

Secondly, an odd thing: for some reason versions-maven-plugin in my POM doesn't seem to realize that itself is out of date; I'm using v2.11.0, but v2.12.0 is available. But mvn versions:display-plugin-updates is only listing other plugins_ as being out of date. Is there some sort of lag before versions-maven-plugin will see a new version? Doesn't it go off Maven Central?

@slawekjaranowski
Copy link
Member

@garretwilson
Copy link

… it was published to central ...

Yes, I understand that. My questions still remain.

  1. Did the plugin-related exclusion configuration @ajarmoniuk added at the last minute make it into v2.12.0?
  2. Why does running mvn versions:display-plugin-updates not recognize that versions-maven-plugin has a higher version than 2.11.0 available, even though 2.12.0 has been published to Maven Central? Is there some sort of lag? Does the plugin access some other database that is different than what we see through the Maven Central UI? Why is versions-maven-plugin not showing that an update is available for v2.11.0?

@maffe
Copy link

maffe commented Sep 8, 2022

I think your local Maven installation queries Central only once a day for known artifacts. Try deleting the data in your local repository.

@andrzejj0
Copy link
Contributor

Try using -U with the maven command.

@slawekjaranowski
Copy link
Member

  1. look at release notes https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.12.0 - it was included

@garretwilson
Copy link

Thanks for info and tips.

@garretwilson
Copy link

Try using -U with the maven command.

The -U switch (in mvn -U versions:display-plugin-updates) fixed the problem; it made Maven go and find the new v2.12.0. I guess it was caching something.

@garretwilson
Copy link

Unfortunately the milestone version dependency exclusion still isn't working for me. I'm starting with this POM:

https://github.com/globalmentor/globalmentor-root/blob/a78abf59b9609fcbd6bf4f41bea0ea35025067f2/pom.xml

Then in my <build><pluginManagement> section I set the configuration like this:

<plugin>
 <groupId>org.codehaus.mojo</groupId>
  <artifactId>versions-maven-plugin</artifactId>
  <version>2.12.0</version>
  <executions>
    <execution>
      <goals>
        <goal>display-plugin-updates</goal>
      </goals>
      <configuration>
        <pluginDependencyExcludes>*:*:*-M*</pluginDependencyExcludes>
        <pluginManagementDependencyExcludes>*:*:*-M*</pluginManagementDependencyExcludes>
      </configuration>
    </execution>
  </executions>
</plugin>

Then from the command line I issue:

mvn versions:display-plugin-updates

I still get this:

[INFO] --- versions-maven-plugin:2.12.0:display-plugin-updates (default-cli) @ globalmentor-root ---
[INFO]
[INFO] The following plugin updates are available:
[INFO]   maven-failsafe-plugin .......................... 2.22.2 -> 3.0.0-M7
[INFO]   maven-release-plugin ............................ 2.5.3 -> 3.0.0-M6
[INFO]   maven-site-plugin .............................. 3.12.1 -> 4.0.0-M3
[INFO]   maven-surefire-plugin .......................... 2.22.2 -> 3.0.0-M7

Why isn't it excluding the *-M* versions as I asked it to?

It looks like it isn't picking up the exclusions at all. If I skip discussing executions and try to to exclude everything for all goals:

<plugin>
 <groupId>org.codehaus.mojo</groupId>
  <artifactId>versions-maven-plugin</artifactId>
  <version>2.12.0</version>
  <configuration>
    <pluginDependencyExcludes>*</pluginDependencyExcludes>
    <pluginManagementDependencyExcludes>*</pluginManagementDependencyExcludes>
  </configuration>
</plugin>

It still doesn't exclude anything. And if I do a mvn help:effective-pom, the effective POM doesn't show any other configuration. Why isn't this configuration taking effect?

@andrzejj0
Copy link
Contributor

andrzejj0 commented Sep 9, 2022

Well, you're using the wrong goal. Those changes were implemented for display-dependency-updates, and not for display-plugin-updates yet.

Display dependency updates wrt plugins and plugin management display plugin dependency updates of plugins with dependencies, like so:

  <build>
    <plugins>
      <plugin>
        <groupId>localhost</groupId>
        <artifactId>dummy-maven-plugin</artifactId>
        <version>1.0</version>
        <dependencies>
          <dependency>
            <groupId>localhost</groupId>
            <artifactId>dummy-api</artifactId>
            <version>1.0</version>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>localhost</groupId>
          <artifactId>dummy-maven-plugin</artifactId>
          <version>1.0</version>
          <dependencies>
            <dependency>
              <groupId>localhost</groupId>
              <artifactId>dummy-impl</artifactId>
              <version>1.0</version>
            </dependency>
            <dependency>
              <groupId>localhost</groupId>
              <artifactId>dummy-parent2</artifactId>
              <version>1.0</version>
            </dependency>
          </dependencies>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

As for the new ask, we could probably do that as well, could you please create another issue?

@garretwilson
Copy link

garretwilson commented Sep 9, 2022

Well, you're using the wrong goal. Those changes were implemented for display-dependency-updates, and not for display-plugin-updates yet. Display dependency updates wrt plugins and plugin management display plugin dependency updates of plugins with dependencies, …

Oh I think I see. So you only implemented pluginDependencyExcludes for plugins of dependencies but not for plugin dependencies themselves?

As for the new ask …

I had assumed that the original <ignoreVersions> exclusion capability applied to display-plugin-updates as well, but maybe I was mistaken. I've opened #684 for this functionality to be completed.

@arjantijms
Copy link

In my case Maven keeps bugging me about the following update:

[INFO] --- versions:2.14.2:display-dependency-updates (specific) @ ldapbp ---
[INFO] The following dependencies in Dependency Management have newer versions:
[INFO]   antlr:antlr ........................................ 2.7.7 -> 20030911

So I excluded this as per the documentation, I think:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>versions-maven-plugin</artifactId>
                <version>2.14.2</version>
                <executions>
                    <execution>
                        <id>specific</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>display-dependency-updates</goal>
                        </goals>
                        <configuration>
                            <dependencyExcludes>antlr:antlr:20030911</dependencyExcludes>
                            <dependencyManagementExcludes>antlr:antlr:20030911</dependencyManagementExcludes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

And I invoke it via;

mvn versions:display-dependency-updates@specific

But it keeps showing the antlr:antlr:20030911 update. What do I need to do to actually exclude it? Am I doing something wrong, or is this a bug in the plug-in?

@andrzejj0
Copy link
Contributor

andrzejj0 commented Feb 21, 2023

Am I doing something wrong

Yes.

You're matching your dependency against a version which you are not using in your pom. You should pin it with the one you're using, e.g.

  • antlr
  • antlr:antlr
  • antlr:antlr:*
  • antlr:antlr:2.7.7
  • etc., etc.

So, in your case,

<configuration>
  <dependencyManagementExcludes>antlr</dependencyManagementExcludes>
</configuration>

should be fine.

@arjantijms
Copy link

With:

<configuration>
  <dependencyManagementExcludes>antlr</dependencyManagementExcludes>
</configuration>

It will not tell me when 2.7.8 comes out, does it?

@andrzejj0
Copy link
Contributor

Oh, snap. You mean filtering on the output dependencies. I guess that isn't working indeed. I wonder if it ever worked. In any case, it should be quite easy to fix.

@andrzejj0
Copy link
Contributor

Created #921

@andrzejj0
Copy link
Contributor

@arjantijms
Copy link

arjantijms commented Feb 21, 2023

You mean filtering on the output dependencies.

Indeed, not sure why one would ever want to filter dependencies you already have, for getting suggestions about dependencies you don't have. The example above specifically is about excluding milestone versions:

<dependencyExcludes>*:*:*-M*</dependencyExcludes>

That's not about the user's pom already being full of *-M* versions, but the user not wanting to get suggestions to update to *-M* versions. The user above literally says so:

And after adding these exclusions, the plugin would no longer say 
that org.apache.maven.doxia:doxia-core had a newer version, 
as the newer version 2.0.0-M3 is a milestone matching the excludes. 

But if a version 1.11.2 came available, it would notify me of that.

So the user want's to exclude the new version 2.0.0-M3; not wanting to have that as suggestion and therefor not update to that. That seemed to be the entire purpose of the option. But now it seems that instead of ignoring the new version, it will ignore 2.0.0-M3 if it's in the pom, and then never suggest say 1.11.2. But that's entirely the opposite of what people want. You do not want 2.0.0-M3 in the pom, and you do want 1.11.2 to be suggested.

Now <ignoredVersions> does work, and it seems to be good enough for my particular use case.

But in general, unless I'm really missing something, it looks like dependencyExcludes is implemented wrongly? #921 is still correct then. As you'd still want to say to exclude suggestions for foo:bar:*-M* and kaz:zak:*-RC*, right?

@andrzejj0
Copy link
Contributor

Glad that it worked for you.

#921 is still correct then. As you'd still want to say to exclude suggestions for foo:bar:-M and kaz:zak:-RC, right?

Well, yes and no. The original intention of this "feature" was to filter the input dependencies. I agree it makes little sense to go over the version there. Maybe a new feature toggle to change the behaviour? I can add one later.

@slawekjaranowski what do you think?

@garretwilson
Copy link

garretwilson commented May 20, 2023

I'm circling back around to finally test this issue and #684. Just to make sure I'm understanding this:

Do I understand the current situation correctly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants