Le sam. 14 août 2021 à 16:52, Enno Thieleke <enno.thiel...@holisticon.de> a écrit :
> You are right, the feature is mainly useful for transitive dependencies. > That's my main motivation anyway. > > Consider the following: > You have a dependency to something that depends on > org.hibernate.javax.persistence:hibernate-jpa-2.2-api. You yourself or > another thing you depend on depends on > jakarta.persistence:jakarta.persistence-api. Both artifacts have pretty > much the same content. As for your classpath, you only want one of both > (transitive) dependencies. But Maven will resolve both, because their > coordinates are different. Here Maven's superpower of selecting the right > version can't come into play. > > As for overrides inside the reactor (no matter the depth), this is mainly > for providing a consistent result. If overrides affect transitive > dependencies, they must also affect dependencies inside the reactor, but > for such overrides a warning should be produced, since they are under your > control. > > I think my example even shows both cases: depending on something you > override yourself and transitively. > Think the question is: do you want to control your dependencies or not. If you want the only option is an exclude (and you can create a pom excluding/adding the one you want, kind of superbom for convenience). Using dependency management is also doable very easily (what we tend to use as of today in project I think). Your proposal is about rewriting a pom dynamically which is really an extension IMHO and proven random with all the spec gav out there (javax->jakarta migrations prove you must not rely on such behavior, it leads to conflict if not explicitly done as mentionned which is a "less worse" solution IMHO). So back to the point it is already doable and built in, you just propose another grammar IMHO. ________________________________ > From: Bernd Eckenfels <e...@zusammenkunft.net> > Sent: Saturday, August 14, 2021 4:31 PM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > I don't really see it convenient at all. If you have to change the source > anyway, you can also fix the POM, that's much less confusing than having a > project using technology x but declaring to use technology y. > > The only time I see dependency overwrites as somewhat useful if you want > to replace transitive dependencies with fixed minor updates. This is > however seldomly needed since maven adjusts version conflicts to the > closest version anyway. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: Enno Thieleke <enno.thiel...@holisticon.de> > Gesendet: Saturday, August 14, 2021 3:38:53 PM > An: Maven Developers List <dev@maven.apache.org> > Betreff: Re: Request for Enhancement: Dependency Overrides > > Hi Bernd, > > hopefully I understand you correctly: I'd expect the artifact (and its > source and javadoc attachment) to change, nothing more. The source would be > left untouched. It is not the responsibility of the dependency resolution > mechanism/engine to do anything else. > > Just to make sure that we have the same understanding: If I replaced one > dependency with another one, I would effectively alter the POM to contain > that other dependency instead of the original. After that Maven would do > its thing as usual. > > Obviously, such a feature should be used carefully: If I replaced > commons-logging:commons-logging with log4j:log4j, any code referencing code > from commons-logging would not compile anymore. It's the responsibility of > the developer to provide a working replacement. But this is fine, if you > ask me, because if I replaced an artifact by exclusion and added a wrong > dependency, the issue would be the same - and this is possible today > already. One could say that an override would be a very, very convenient > way the exclude and add a dependency. > > Kind regards, > Enno > > ________________________________ > From: Bernd Eckenfels <e...@zusammenkunft.net> > Sent: Saturday, August 14, 2021 2:28 PM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Would you expect to only replace artifacts or also change the java source > and class files to actually change the used classes? Your cases are no > simple drop-in replace compatibility. Therefore I doubt a maven feature to > do so is any more useful than just blocking the deprecated artifacts. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: Enno Thieleke <enno.thiel...@holisticon.de> > Gesendet: Saturday, August 14, 2021 1:24:26 PM > An: Maven Developers List <dev@maven.apache.org> > Betreff: Re: Request for Enhancement: Dependency Overrides > > 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. > > 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. > ________________________________ > 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 > > > > > > > > >
