Could you please elaborate on why a registry would be necessary? What kind of registry are we talking about (what would its purpose be)?
Profiles should not be an issue since they should be merged into the model at a very early stage, even before dependency management kicks in, right? Hence there's no or little development needed here. If a profile contains overrides, they'd be merged into the model as if they were there from the start (at least that's how I imagine it would be). ________________________________ From: Romain Manni-Bucau <rmannibu...@gmail.com> Sent: Saturday, August 14, 2021 2:08 PM To: Maven Developers List <dev@maven.apache.org> Subject: Re: Request for Enhancement: Dependency Overrides Le sam. 14 août 2021 à 13:24, Enno Thieleke <enno.thiel...@holisticon.de> a écrit : > So, you're saying that I can replace artifact coordinates with > dependencyManagement.dependencies already? I'm not talking about versions, > scopes and exclusions, I'm talking about groupIds and artifactIds. My idea > is, simply put, if artifact commons-logging:commons-logging is found, > org.slf4j:jcl-over-slf4j is used instead. Or if artifact > org.hibernate.javax.persistence:hibernate-jpa-2.2-api is found, > jakarta.persistence:jakarta.persistence-api is used instead. I don't think > that this is possible with the current version of Maven. If it is, please > share a link to the docs covering this feature. > I see This clearly sounds like an extension scope since it will quickly need a registry and profiles as feature and I dont see it fitting maven (would make it too complex). Without these features it is almost useless since dependency management or a pivot pom give you enough control to enforce the artifact you want. > Feel free to look at the example I provided. I feel it makes my idea more > comprehensible. > 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 (the > "magic" happens in the parent/root POM) > > Also, I don't think implementing this as an extension is the right thing > to do. If it were to be fully implemented, it'd have to be a core feature > of Maven and the Maven Resolver. This way the entire user base of Maven > would benefit from it. > Most of maven consumers dont use maven resolver so I dont agree with that last part and is one of the multiples reasons I think it must not be a core feature (added to the previous mentionned facts). ________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> > Sent: Saturday, August 14, 2021 8:55 AM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Hmm, > > dependencyManagement.dependencies already does that today. > My point is mainly we shouldnt have two ways to do the same and even less > two chained ways to do it. > > If you dont like mvn dep graph definition you can already write a mvn > extension to write it differently so can also be an option, but as of today > i dont see anything not already smoothly doable. > > Le sam. 14 août 2021 à 02:01, Enno Thieleke <enno.thiel...@holisticon.de> > a > écrit : > > > Hi Romain, > > > > the dependencyOverrides element is an addition. While it shares some > > characteristics, it does not duplicate the dependencyManagement element. > In > > fact, it's a part of it. Come to think of it, it may even be ok to > > locate/place it "next to" the dependencyManagement element, thus making > it > > a "standalone thing", but I consider this feature to be a > > dependencyManagement aspect, which is why I made a sub element of it. > > > > I'm not sure if I understand your question correctly: how to override in > > the override block? > > If you mean how would a dependencyOverrides element of one POM be merged > > with an element of another POM, pretty much like a dependencyManagement > > element - I made sure remove redundant sub elements. > > If you mean how would an override override another override? Currently > > processing overrides is just a sequential operation. Let's say the order > of > > overrides is as follows (the notation "->" is to be read as "is > overridden > > with" or "is replaced by"): > > > > * X -> Y > > * Y -> Z > > > > Here having a dependency X will ultimately result in having Z. And now > for > > a different order: > > > > * Y -> Z > > * X -> Y > > > > Here having a dependency X will result in having Y. > > > > I think a helpful implementation would raise an error in both cases, > since > > having some sort of hyper edge here is questionable. > > > > Where I'm definitely not following you is why one would drop the > > transitiveness of an override block/element. On the contrary: I'd not > touch > > transitiveness in any way. If an override brings transitive dependencies > > where an original didn't, then so be it. That'd actually be desired in my > > opinion. > > > > The final goal of overrides (if you ask me) is to manipulate a dependency > > graph in a way that is transparent to developers and plugins. If done > > right, one wouldn't be able to tell the difference between a graph, which > > is clean from the start, and a graph, which has been altered using > > overrides. > > > > Looking forward to your reply. > > > > Kind regards, > > Enno > > > > > > ________________________________ > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > Sent: Friday, August 13, 2021 2:41 PM > > To: Maven Developers List <dev@maven.apache.org> > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > 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 <enno.thiel...@holisticon.de > > > > 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 <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 > > > > > > > > >
