-
Notifications
You must be signed in to change notification settings - Fork 267
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
Comments
This would also avoid the problem with multi-module projects and having to use the |
Hi, everyone! Completely agree with the previous authors. The requested functionality is quite essential, so it would be great to have it. Best regards, |
Dear maintainers, Please, consider re-opening this GitHub issue. Best regards, |
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? |
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. |
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 This will land in today's release (2.12.0). @slachiewicz |
@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 |
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:
Version 2.12.0 will introduce new arguments: 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:
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 😄 ). |
Woohoo! @ajarmoniuk you don't know how excited I am to try this out.
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! |
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 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). |
Yes, you seem to understand it correctly. Well, it's quite complex actually. Include means only show the dependencies satisfying the filter. Set<Dependency> onlyIncludes = includeDeps.retainingIn( dependencies );
Set<Dependency> filtered = excludeDeps.removingFrom( onlyIncludes ); |
…cludes/excludes
…cludes/excludes
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. |
…includes/excludes
…includes/excludes
…includes/excludes
…includes/excludes
@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 |
@garretwilson it was published to central ... https://search.maven.org/artifact/org.codehaus.mojo/versions-maven-plugin |
Yes, I understand that. My questions still remain.
|
I think your local Maven installation queries Central only once a day for known artifacts. Try deleting the data in your local repository. |
Try using -U with the maven command. |
|
Thanks for info and tips. |
The |
Unfortunately the milestone version dependency exclusion still isn't working for me. I'm starting with this POM: Then in my <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:
I still get this:
Why isn't it excluding the 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 |
Well, you're using the wrong goal. Those changes were implemented for 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? |
Oh I think I see. So you only implemented
I had assumed that the original |
In my case Maven keeps bugging me about the following update:
So I excluded this as per the documentation, I think:
And I invoke it via;
But it keeps showing the |
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.
So, in your case, <configuration>
<dependencyManagementExcludes>antlr</dependencyManagementExcludes>
</configuration> should be fine. |
With: <configuration>
<dependencyManagementExcludes>antlr</dependencyManagementExcludes>
</configuration> It will not tell me when 2.7.8 comes out, does it? |
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. |
Created #921 |
Already implemented. |
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
So the user want's to exclude the new version Now But in general, unless I'm really missing something, it looks like |
Glad that it worked for you.
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? |
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? |
I think it would be convenient if I could specify versions to ignore directly in
pom.xml
under theconfiguration
tag. Then I would not have the need to create an extraRules.xml
file, but could simply specify everything directly in the pom:The text was updated successfully, but these errors were encountered: