Hi Michael, thank you for your answer.
An interesting thought. It never occurred to me that a global exclusion would help in a similar way, but then again, global excludes aren't a thing, yet (are they?). I think excluding globally and including a specific dependency as a replacement is not as clear as having an override element in a POM. The former can simply be read as: "Aha, a global exclusion here" and "Huh, a runtime dependency there." A good developer would surely add a comment or two to make his/her intention clear. The latter implies the intention in the very construct that is used. Also with global exclusions, when analyzing a (verbose) dependency graph, it wouldn't show excluded dependencies. Sure, this is the expected behavior, but again, it's not what a proper graph should look like if overrides/replacements were a thing. If A depends on B and B has been replaced with C, then I'd expect to see C instead of B or better yet, see that B has been omitted in favor of C. While reading the comments of MNG-1977 I found https://issues.apache.org/jira/browse/MNG-5652 which is a bit more like what I have in mind. Since even my proposal is in a very early stage (not to mention the code I've written), I neglected to mention that I also want to make overrides be importable via the "import" scope. This way one can simply import a BOM as usual and benefit from any dependency cleanups done by others. My assumption is that providing overrides in a BOM is a somewhat "frameworky thing" (e.g. Spring, Java/Jakarta EE). One example for a use case is my all-time favorite org.wildfly.bom:wildfly-jakartaee8:20.0.1.Final. It includes a managed dependency for Hibernate with some exclusions to it. Now, when using this managed dependency, I must manually add the exclusions (with the correct coordinates), which are actually missing, hence not provided via some other coordinate in the graph of said managed Hibernate, which is somewhat painful. In essence, I think global excludes are definitely a good tool to have, I just don't think that they are the right tool when it comes to replacing dependencies in a concise way. Please let me know what you think. Kind regards, Enno ________________________________ From: Michael Osipov <micha...@apache.org> Sent: Wednesday, August 11, 2021 4:31 PM To: dev@maven.apache.org <dev@maven.apache.org> Subject: Re: Request for Enhancement: Dependency Overrides Am 2021-08-06 um 17:55 schrieb Enno Thieleke: > Hello, > > I've been using Maven for 10+ years now. It's great and I still prefer it > over similar tools. Recently I encountered a scenario where it would have > been nice to be able to simply "override" a dependency. For example by > specifying _somehow_ that (in my case) commons-logging should be > jcl-over-slf4j in the entire dependency graph of my project. > > Now you might think: "That is what exclusions are for". And I agree to some > extent. But if I exclude a dependency (maybe just once, maybe many times) and > add a dependency to my project to replace what I have excluded, this newly > added dependency violates the convention of only having (direct) dependencies > you want to program against. But in this case, it is not my intent to use > commons-logging and since it is not used in my code, some other developer or > plug-in might consider it redundant or obsolete. > > I encountered other dependencies I'd like to override too. Generally > speaking: Whenever some artifact needs to be replaced by a different one, > which has a different groupId or artifactId, overrides might come in handy. > Consider the artifactId jboss-jaxrs-api_2.0_spec and its newer version > jboss-jaxrs-api_2.1_spec. It has version information encoded into it. This is > an issue the Maven resolver is not able to handle nor is it designed to > handle it. > > Long story short, I've found a ticket for something like this: > https://issues.apache.org/jira/browse/MNG-4530 > I also started to implement this feature (albeit differently from the > suggested approach in the ticket): > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530 > https://github.com/strohmattenverleger/maven/tree/MNG-4530 (requires the > changes I made to maven-resolver) > https://github.com/strohmattenverleger/maven-MNG-4530-example > > If you find the time, please look at what I've implemented so far. In the > example project you will find the maven-dependency-plugin configured to copy > the project dependencies. I've spoken to some of my colleagues and they > wanted me to also look the results of "mvn dependency:tree" which turned out > to be as expected (commons-logging has been replaced entirely). Please keep > in mind, that the feature is not finalized - it's more of a PoC. > > I would like your opinion on whether this feature would be nice to have and, > if so, if the approach is the right one. I'm open to suggestions and I'd be > happy to answer your questions. If you think this feature has what it takes > to be merged into Maven once it's finished, I'd be willing to invest more > time into it. Hi Enno, I think you request could be/is related to https://issues.apache.org/jira/browse/MNG-1977. You brought up the most common example for this: Commons Logging. We obviously not only need global excludes, but also global overrides. But I think global overrides can be achieved somewhat by global excludes and a runtime dependency with a comment above. It is not as elegant as your proposal, but would ultimately solve the problem with a different dependency tree. M --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
