Hmm, I probably miss a thing but it looks like you just redid dependencyManagement but duplicating it you created a new issue: how to override in the override block? Only neat way I see to handle that is to drop the transitiveness of the override block which would defeat a lot dependency usage so I'm quite mixed about this proposal without a more concrete use case.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 13 août 2021 à 12:56, Enno Thieleke <[email protected]> a écrit : > 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 <[email protected]> > Sent: Wednesday, August 11, 2021 4:31 PM > To: [email protected] <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > >
