Le dim. 15 août 2021 à 18:19, Enno Thieleke <enno.thiel...@holisticon.de> a écrit :
> This will most likely be the last answer I'll give you, because I don't > see any constructive criticism on your part. All you're saying is that it's > redundant here and not helping there. Although it would help many people a > great deal and I've showed you. > > > It is the definition of an exclude+include. A replacement means A is NO > more there. > That's why I said it's logically. The dependency node in the graph is > still there. It's just not A anymore, but B (i.e. the contents of the node > have been replaced, not excluded). > If you removed a dep from the dep tree you excluded it, nothing to discuss there, your grammar does not show it but mathematically it is what you did. > > It is required, you showed it with your log example, will not survive > time - at least no more than a PoC. > If by that you mean that you won't find A anymore if you do a > dependency:tree, then yes. And I said earlier that the output might need to > be improved. > No, i meant it is not maintainable in time to have done it. > > Look at javax/geronimo/redhat/jakarta deps, this problem is there for > more than 10 years and your proposal does not change that > You're right, my proposal doesn't change that nor is meant to. It's meant > to help you as a developer to write concise POMs that don't suffer from the > issue/problem you mentioned. > So once again you only solve a verbosity issue at the wrong level IMHO. > > Dep mgt goal is to be global for the subtree, this is not overkill. > Overrides is since at the end it does the same slightly differently. > "Slightly differently" is the understatement of the year so far. Writing > ONE snippet of XML instead the same one repeatedly or worse entire POMs and > BOMs is not overkill, it's helpful. > Once again it is *wrong* as explained to you multiple times with dep mgt or pivot pom. > > Once again the natural way is to use dep mgt as documented, what is the > point of override? > There's no such thing as a natural way in this case. Dependency management > has been designed by humans and it can be changed by humans. If we > constrained ourselves to stuff that's already out there, we wouldn't have > come far. Please show a bit more open-mindedness in this regard. > Natural= the way. You create another sibling one whichbis bad IMHO. > > Once you start to use override and you also consume the override where > do you put it? In both locations? > The true power of overrides come into play when resolving dependencies > that are not part your reactor. Applying overrides to dependencies inside > your reactor is for consistency. I'd also go so far and implement a warning > that you use an override in your reactor, because those dependencies are > under your control. The transitive dependencies are not. As a side note: I > would not want to allow artifacts of your reactor to be used as overrides, > because that could lead to cyclic dependencies. > It is always in your reactor somehow and does not change much the issue. > > Please use all resolvers not relying on maven deps, they are numerous > out there. > Definitely not. This feature is a Maven thing. Maven provides all the code > that's necessary to resolve artifacts. If somebody (a person or a company) > reimplements the Maven Resolver, then it's their responsibility to keep up > with Maven's development. > No, you dont like maven style so propose an alternative, be it, but it is an extension IMHO. > > We are not gradle and dont want to force all repo to embed our wrapper > or binaries because we keep breaking ourselves IMHO. > Amen. Although Gradle has the concept of replacements: > https://docs.gradle.org/current/userguide/resolution_rules.html#sec:module_replacement > I appreciate the fact, that the Maven developers try to keep Maven and its > plugins to be as compatible as possible. But sometimes changes are in > order. And when a new major version is knocking on your door, why not > include such changes? > Consumed pom version will never change. Compat of central is what makes it useful, no discussion on it and why i spoke on consumed pom. > > Take your bom example. You dont want to override 3-4 deps but a full > transitive subtree. > Overriding an entire subtree is a as simple as writing one override - it > cuts off anything below, because the original has been replaced and > therefore all its transitive dependencies. If you want to replace specific > leaves in the graph and many of them, then yes, it'd be verbose. But not > more than using exclusions. > Try it, override an overriden dep comes quickly and you are back to the original issue so why another way to do the same. > > The resolution must stay a tree one to be maven compliant so not sure it > brings anything here again. > Not gonna lie, I don't understand what you're trying to say. > You create a 2 roots tree, it is very hard to maintain in practise. > > This is well solve using dependency plugin and dep/dep mgt sections > *already*. > It isn't. It just isn't. Otherwise, people wouldn't be requesting it for > years now. Are you saying that _all_ of these people don't know how to use > Maven? They do and they found a weak spot and are suggesting a concept to > improve Maven. > People do, look camel, cxf, tomee, openwebbeans, meecrowave, microprofiles impl, spring, quarkus etc... Im also fine reasoning the other way around, use your override proposal, make it evolve 3 generationz (groupid change, artifact change, and whatever other change) and look how similar you are to current state or full of debt (useless overrides, misleading deps/dep mgt) for 1 jar, do the exercise please, I did years ago using attributes and it was not satisfying after 1 cycle. > > So your goal is to bring a shortcut so to work on pom verbosity only as > I explained. This is not from where it should be tackled IMHO. > Then bloody come up with a better idea. There's no doubt that there's a > gap to be filled here and I'm taking action. What will you do? > Im fine documenting how to write a pom module if insufficient - which is likely the best/cleanest/easiest to maintain solution in time. Excludes/dep is also fine when local IMHO. With these two options you cover all overrides cases. > > Not using dep mgt and/or packaging=pom modules, just give it a try. It > is clean, maven aligned and neat at the end. > Not gonna happen. I know that I don't want to maintain many additional > POMs. So you dont want to maintain override, understand it is 1-1. Also, I'd have to use different coordinates to resolve, say, Hibernate. I'd > have to use something like com.mycompany:hibernate-with-jakartaee8-deps:pom. Yep which is what you will use instead of faking using hibernate and actually using openjpa because of an override. Really misleading for a pom reader. And it still wouldn't result in a clean graph since the addition of the > correct dependencies are in the POM, not in Hibernate (as far as the graph > is concerned). > Graph will be perfectly clean and what you ask, not sure wh it wouldnt since it is the goal here. > As mentioned earlier: If you have nothing of value to contribute here, I'd > want you to keep out of it from now on, since you are no member of the > Maven PMC. I'll consider your opinion as a -1 but ultimately it is not up > to either one of us, but to the PMC (and whomever the deem worthy) to > decide in this matter and I really hope that I'll get a more qualified and > strong opinion from them. > This is true but more than PMC user opinion is important. What I humbly request you is to not explain them the magic you propose them but how it will be misleading and lead to errors in enterprise (once again you read logback and have log4j for example with your proposal). > Ftr: I just want to know whether this is worth my time or if I can simply > stop at this point. If this feature has the stuff to make it into Maven, > then details need to be worked out and I'd be willing to implement most if > not all of it. > What about looking for a simple meta/pom module def instead of an override option? Pom modules can be defined in root pom IMHO and easily exported as consumable poms, what about it rather than a misleading grammar? > ________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> > Sent: Sunday, August 15, 2021 3:07 PM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Le dim. 15 août 2021 à 14:29, Enno Thieleke <enno.thiel...@holisticon.de> > a > écrit : > > > An override is not an exclusion - it enforces a replacement. In other > > words: A becomes B, so A is still there, but rather logically than > > physically. > > > > It is the definition of an exclude+include. A replacement means A is NO > more there. > > > > > Also, I don't see the need for a dependency:check-overrides mojo. I trust > > in the abilities of developers (until proven otherwise). If someone > > replaced an artifact with an incompatible one, it would be a mistake one > > makes only once, and it's no big deal since people learn all the time. > > > > It is required, you showed it with your log example, will not survive time > - at least no more than a PoC. > Look at javax/geronimo/redhat/jakarta deps, this problem is there for more > than 10 years and your proposal does not change that at all so if you > complexify the analyzis, you must tool it way stronger too. > > > > > Concerning your point, that it's overkill to have multiple ways the model > > a dependency graph: I disagree. If that were true, dependency management > > would be overkill entirely, because all that's done by dependency > > management can be done without it - just not in a concise way. > > Maven is all about a strong declarative approach, which is why shortcuts > > are needed. You could model all exclusions and dependencies manually > (have > > fun doing that in a huge multi module project), or you could use > dependency > > management to help you express something like "whenever A is used, use > the > > version X und exclude Z" (the is what one managed dependency could and > > should be read and interpreted as). I merely want to add one thing to > this > > management feature: "whenever A is used, use B instead". > > > > Dep mgt goal is to be global for the subtree, this is not overkill. > Overrides is since at the end it does the same slightly differently. > > > > You say that Maven is verbose in general. I agree. But that is totally > > off-topic (although I'd really love to see Maven use XML and utilize > > attributes). > > > > Now to the drawbacks you listed: > > > > 1. users don't know anymore where to do things > > Oh, but they do. The XML elements are self-explanatory. Exclusions > > exclude, overrides override. If you think that the elements are not > > self-explanatory, then please suggest different names or locations in the > > POM. As mentioned earlier, I provided a PoC, something up for discussion, > > not a final solution. > > > > Once again the natural way is to use dep mgt as documented, what is the > point of override? > Once you start to use override and you also consume the override where do > you put it? In both locations? > Just makes a mess for dev IMHO. > > > 2. you break most of the tooling related to maven > > My PoC doesn't break any tooling that I'm aware of. Dependency resolution > > works better than before IMO and plugins don't need to be changed - I > > tested it with dependency:tree and help:effective-pom. While the output > of > > the latter could be improved, it does show the truth. But again, please > > keep in mind, that we're talking about a PoC for a feature of a new major > > version of Maven and according to semantic versioning, breaking changes > are > > allowed when changing the major version. > > Concerning the model version change from 4.0 to 4.1: If that breaks some > > plugin or tooling, then the affected code needs some work anyway. > > > > > Please use all resolvers not relying on maven deps, they are numerous out > there. > Use coursier for example. > The "they will be updated" - all IDE and plugins and resolvers - is a weak > answer I dont consider as an option. > We are not gradle and dont want to force all repo to embed our wrapper or > binaries because we keep breaking ourselves IMHO. > > 3. it requires profiles to be useful for boms > > I see this as claim at this point, nothing more. Please elaborate and > > provide an example. > > > > Take your bom example. You dont want to override 3-4 deps but a full > transitive subtree. > This will be insanely verbose until you can import overrides from another > bom somehow - not inheriting from dep mgt which seems to be your target. > This is what was behind the profile idea. > Also think to conflict resolution there too. > Makes really the pom a mess with dependency management in too much > sections. > > 4. it has the exact same pitfalls than current blocks so you will need > > an overrideOverride block in a few months > > Yes, it does have the same pitfalls. These are pitfalls we'll never, ever > > get rid of. Provide a wrong replacement, no matter what mechanism you use > > (exclusions or overrides), and your code won't run. Plain and simple. > > Also, no you wouldn't need an overrideOverride to solve an issue like > > this. You'd just redefine the override in your project or module. The > > "original" artifact is used to identify the override on a per module > basis. > > So, defining B to be used instead of A is globally possible, but can be > > replaced with C is to be used instead of A in a different POM. At least > > this is how I intend it to work. > > > > The resolution must stay a tree one to be maven compliant so not sure it > brings anything here again. > > > 5. does not solve the broken BOM definitions which seems to be where > > your issue is coming from > > My motivation is not coming from "broken" BOM definitions alone. If I > > wasn't using BOMs at all, I'd still face the issue of having to clean up > my > > dependency graphs. > > > This is well solve using dependency plugin and dep/dep mgt sections > *already*. > > Also, ask yourself why those BOMs are "broken" in the first place: it's > > because there's no shortcut to clean up the mess, yet. > > > > So your goal is to bring a shortcut so to work on pom verbosity only as I > explained. > This is not from where it should be tackled IMHO. > > My motivation also comes from the fact that I don't want to repeat myself > > over and over again, which I what must do if I use exclusions. > > > > Not using dep mgt and/or packaging=pom modules, just give it a try. It is > clean, maven aligned and neat at the end. > > > > ________________________________ > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > Sent: Sunday, August 15, 2021 8:35 AM > > To: Maven Developers List <dev@maven.apache.org> > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > Le sam. 14 août 2021 à 22:21, Enno Thieleke <enno.thiel...@holisticon.de > > > > a > > écrit : > > > > > Ok, I feel like we're turning in circles here. > > > > > > If the feature I'm proposing exists already (without excludes and > without > > > the need for extra POMs and BOMs, i.e. the common solution), please > post > > a > > > link to the docs. If it doesn't exist and people ask for it [1] (and > have > > > been for years), then I don't see why you'd want to reject it. > > > > > > > It requires excludes, as your proposal does (since to override a jar you > > need to list the excluded one, this is literally an exclude even if you > > name differently the tag). > > Since it can be done globally in the dep mgt it is exactly what you > request > > except you control your dependencies whereas you want to apply rules > > without knowing if they are useful so it means you will need to add a > > dependency:check-overrides mojo just for that purpose and users to run it > > which is overkill as having 2 ways to do the same thing IMHO. > > > > > > > > > > The common solution is cumbersome and verbose. Why somebody would > prefer > > > it over a more concise XML element is beyond me. > > > > > > > It is not really and, once again, most of maven definition can be seen as > > verbose - but here it is the same as your proposal. > > If you want to tackle verbosity it is another topic whith way more items > > than this one (the artifact definition likely being inlining as a first > > item). > > > > > > > > > > You say it brings drawbacks. What are they? Please elaborate. > > > > > > > The one I listed: > > > > 1. you duplicate the definition so the pom reading is less straight > > forward + users don't know anymore where to do things > > 2. you break most of the tooling related to maven and must drop this > > section in the pom producer (so you dont solve the verbosity issue for > > consumer) > > 3. it requires profiles to be useful for boms (not <profile> but > > <overrideProfile>jakarta</> for ex) > > 4. it has the exact same pitfalls than current blocks so you will need an > > overrideOverride block in a few months > > 5. does not solve the broken BOM definitions which seems to be where your > > issue is coming from > > > > > > > > > > > > [1] > > > https://issues.apache.org/jira/browse/MNG-4530 > > > https://issues.apache.org/jira/browse/MNG-5652 > > > https://issues.apache.org/jira/browse/MNG-1977 > > > <https://issues.apache.org/jira/browse/MNG-5652> > > > ________________________________ > > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > > Sent: Saturday, August 14, 2021 8:14 PM > > > To: Maven Developers List <dev@maven.apache.org> > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > Le sam. 14 août 2021 à 18:56, Enno Thieleke < > enno.thiel...@holisticon.de > > > > > > a > > > écrit : > > > > > > > You're right. Currently, if I want to control my dependencies, I must > > > > resort to excludes and define the dependencies I really want myself. > > And > > > > putting something like that in one or two POMs and aggregating them > in > > a > > > > BOM is very dirty in my opinion. Not only is it noisy/verbose when it > > > comes > > > > to writing XML, it also adds nodes to the dependency graph where they > > > > shouldn't be - not to mention unnecessary indirections. > > > > The need for overrides is becoming bigger and bigger. As the Maven > > > > ecosystem grows, artifacts with practically the same content but with > > > > different coordinates are becoming more frequent. > > > > > > > > > > I disagree, your solution is 1-1 with existing one, just somewhere else > > > which is one pitfall as mentionned. > > > It is also not new and solved since at least ten years so not sure what > > is > > > specific for you here and what makes the common solution less practical > > or > > > verbose. > > > > > > > > > > > > > Whether my proposal is about rewriting a POM dynamically is unclear > at > > > > this point. I came here to propose the feature of overrides and > > provided > > > a > > > > simple PoC, not the final solution. What I consider to be clear at > this > > > > point is that overrides need to exist in Maven as a core feature, not > > as > > > an > > > > extension, because this way the Maven Resolver can be changed as well > > to > > > > honor the feature which would enable overrides to work transitively > > (all > > > > part of the PoC). > > > > > > > > > > It is already there, definition is deterministic and fully defined. > > > Verbosity is a thing but then you want g:a:v definition too if you want > > to > > > tackle it so I assume it is out of topic. > > > > > > > > > > > > > To your point: Yes, you can do all the stuff we're talking about > today > > > > already. Just not in a convenient way with a clean result - the > > effective > > > > result is just "good enough". > > > > > > > > > Once again, 1-1 with your proposal as of today since you just meta > define > > > deps in it. > > > > > > > > > This brings me back to writing POMs and BOMs for "overriding" > > dependencies. > > > > That's a lot of work. If one snippet of XML - a different grammar - > > does > > > > all that, then I'd gladly take it. > > > > > > > > > > Isnt it xlst ;), can be another way to impl it with mvn 4 but still > not a > > > core feature IMHO. Brings more drawbacks and no new feature. > > > > > > ________________________________ > > > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > > > Sent: Saturday, August 14, 2021 5:08 PM > > > > To: Maven Developers List <dev@maven.apache.org> > > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
