Hi Enno, Reusing import in another block with another semantic has too much drawbacks for me:
1. it makes the meaning different depending where it is used 2. you need to create a kind of bom for overrides which is not really the intent/will on user side (you literally want an exclude/include mecanism) I still have issues with transitivity with this feature, both cases are valid (using it or not) but if we enable it then we break easily projects with > 1 import level so guess we don't have the choice to not use it which means a consumed project with imports must rewrite the pom to promote imports as excludes - exactly as you do to day without tat feature - to keep modelVersion=4.0.0 and the artifact consumable so not sure the gain is that huge since at the end and as mentionned you *already* have that feature: create a packaging=pom module and use it instead of the direct artifact you want to use if you care about repeating some dependency. I perfectly understand the quickfix spirit in case of a CVE but at the end we are already tooled for that (dependency plugin, oss index etc) so as a developer you don't gain much and technically once you have excluded/included the dep you want in a consumable pom you are iso having imports in the parent so it is a one time work if properly setup so I kind of still think we don't need to make the dev life more complex but maybe document it and worse case enhance dependency plugin to do that for you: mvn dependency:replace -Ddependency.replace.from=javax.foo - Ddependency.replace.to=jakarta.foo. In other words this can be thought more in terms of process than model feature which simplifies a lot the learning curve, usage, integration and way of doing for end users. 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 lun. 20 déc. 2021 à 21:26, Enno Thieleke <enno.thiel...@holisticon.de> a écrit : > Hello again, > > judging by the increased traffic in this mailing list some of you seem to > be on vacation. That's nice. I was hoping that this might be a good time to > ask for your opinion again about what I wrote a couple of weeks ago? > > Kind regards > Enno > > ________________________________ > From: Enno Thieleke <enno.thiel...@holisticon.de> > Sent: Friday, December 3, 2021 10:54 AM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Hi, > > concerning the request to change the override XML element to a > fully-fledged dependency, thus removing the need for accompanying managed > dependencies... > > tl;dr > I would add a version attribute, nothing more, to the override XML > element. The rest would remain unchanged. > > Full version: > > If I turned the override XML element into a fully-fledged dependency, > should we support properties such as `scope` and `optional`? In my opinion > we shouldn't, because that's still subject to original dependency > definitions, not overrides. If people want to change the scope or add > exclusions, they should stick to dependency management. That's what it's > there for. > I think it's enough to just add a version child-element to the current > override XML element. That would remove the need for accompanying managed > dependencies for just versions and in many simple cases that'd suffice, > wouldn't you agree? I think we should draw the line here between changing > artifact coordinates, a special kind of dependency management, and managing > other dependency properties -> separation of concerns. > Suppose I added a version child-element, I'd still have concerns about > moving dependencyOverrides up one level so that it would be a sibling of > dependencyManagement. Imagine I moved dependencyOverrides up one level. How > would we import them properly? Currently importing a POM imports both: > managed dependencies as well as overrides and I think that wouldn't be the > right approach anymore. Would special import XML elements do the trick? > Such as this: > > <dependencyManagement> > <dependencies> > <dependency> > ... > <scope>import</scope> <!-- Imports managed dependencies --> > </dependency> > </dependencies> > </dependencyManagement> > <dependencyOverrides> > <imports> > <import> <!-- Imports overrides; the packaging of the import MUST be > pom --> > <groupId/> > <artifactId/> > <version/> > </import> > </imports> > ... > </dependencyOverrides> > > To be honest: I think that'd suck. Another way would be to introduce a new > special purpose scope, but I think the existing special purpose scope > "import" is perfect: it's meant to import dependency management information > from different POMs and since overrides affect dependencies in the sense > that they manage dependency coordinates, we're still talking about > dependency management. > > Please let me know what you think. > > Kind regards > Enno > > ________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> > Sent: Monday, November 22, 2021 2:33 PM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <enno.thiel...@holisticon.de> > a > écrit : > > > Hello, > > > > @Delany, regarding 1 and 2: If I added all the other elements of the > > dependency tag, I would have to apply dependency management anyway if > > present (and I played around with it for a bit), but I see your point. > > Maybe using the dependency tag (I'd still name it override though) is > "good > > enough" for small projects/POMs. I will throw a bit of time at it and > check > > for "bad" implications. > > > > Making the override tag optional to have some sort of global exclusion > > mechanism is out of scope. Let me explain: When dependency management > comes > > into play (in maven-resolver), it is not designed/intended to suddenly > have > > no dependency at hand to work with. The dependency node in the graph > > already exists and the only thing that's left to do is filling it with > the > > right information. I would have to rewrite/change that code as well. I.e. > > the code would have to check for a dependencyOverride with a matching > > original with no override. To be honest, I personally find that to be > > confusing. An exclusion should be explicit, because it carries a lot of > > weight in my opinion. The absence of an XML element should not make for > an > > exclusion. Global excludes should exist though, just in a different way. > > > > @Romain, I disagree that not defining the version in an override could be > > a source of big issues, because it would have to be defined in dependency > > management anyway, so it's basically there. Changing the major version is > > possible, even today, simply by using dependency management. It is the > > responsibility of the developer to provide a proper override (which is > why > > I suggested a different name, dropinReplacement, to make the intent > > clearer). Still, as stated earlier, I will see what I can do. No promises > > though. :) > > > > I never said I like that but it is what it is so "it would have to be > defined in dependency management" is an assumption you cannot do and is > erroneous and I don't see us saying you can't use this override feature > and/or we break your project if you do so I guess we don't have much choice > than baking it completely and not half. > > Keep in mind dependencyManagement does not behave as dependency override > but that it solves similar issues (controlling your dependency graph for > submodules since in a single module it is not that useful and excludes are > more straight forwards) so as an user you will want to put it in the same > (root? ;)) pom to keep the maintenance easy - spreading overrides in all > poms is not easy to handle in time, this is why mgt block beats dependency > for ex in multimodule projects, I don't see why it wouldn't be the same for > overrides. > > Alternatively we can fail if we hit this case to prevent overrides in such > a case, can be okish in first versions maybe? > > > > > > I agree, having 2 dependencies with the same coordinates but different > > versions is a common thing. But in a single Maven module maven-resolver > > would see to it that there's only one version on the classpath. After > all, > > we're not talking about OSGi (thank god). It's different for multiple > Maven > > modules though and you know it, so I won't elaborate. > > > > Would mean you forbid overrides in packaging=pom modules, not sure it would > be that useful to do so since you would duplicate the override in all > modules. > Makes a lot of noise compared to excludes in a depMgt block form my quick > tests so guess it is not the intent ;). > > > > > > And yes, overriding the classifier (and extension/type) should be > possible > > too. And it already is, but it needs more testing, which I'm working on. > > > > 👍 > > > > > > Kind regards > > Enno > > > > ________________________________ > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > Sent: Monday, November 22, 2021 11:00 AM > > To: Maven Developers List <dev@maven.apache.org> > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > Hi all, > > > > I fear not defining the version is likely a source of big issues and > worse > > than not having this feature at all since often, when you change the > major, > > you change totally the dependency and the override will just not work. > > You can indeed say you must not have 2 dependencies in different versions > > but it is what it is and it is not that uncommon - in particular for libs > > (and if you want to force a single version you use dependency > management). > > So if this feature is desired I fear it must include the version and > likely > > manage the classifier as well to work. > > > > 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 lun. 22 nov. 2021 à 10:14, Delany <delany.middle...@gmail.com> a > écrit > > : > > > > > Hi Enno, > > > > > > On point 1, figuring out the order of events in a build can be > > challenging > > > for newbies since Maven is declarative. For example profiles are > resolved > > > early on and this is reflected by their place in the pom. Although > that's > > > really about config composition, having the overrides under project > could > > > also hint at their special nature. No strong argument to make. > > > > > > Point 2, you say you are following a separation of concerns, but it > seems > > > rather you are forcing one. By requiring dependency management the > result > > > is a tight coupling between stages of resolving the final dependencies > > (not > > > being self-contained, you probably *should* make dependencyOverrides a > > > child of dependencyManagement). > > > Maven doesn't require managing dependencies, but your overrides do. > > There's > > > no harm in picking up config provided by DM, but why force the > > > relationship? If someone wants to add an exclude at the time of an > > > override, frankly that should just be "not your problem". Reusing an > > > existing structure is surely preferable to inventing another one? Would > > the > > > enforcer rules have to learn about your new structure? > > > I see why you went the path of only groupId:artifactId - you copied the > > > exclusion structure. But then excluding doesn't require DM. > > > > > > You're right about wrapping the lists. Will you at least allow not > > defining > > > a dependency at all, aka a global exclude? > > > > > > Delany > > > > > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke < > enno.thiel...@holisticon.de > > > > > > wrote: > > > > > > > Hi, Delany, > > > > > > > > thanks for the feedback. > > > > > > > > I get your point that management and overrides can be seen as > > > independent. > > > > To be honest, I'm really not picky about where in the POM overrides > > > should > > > > be located. I was hoping for opinions on this from others (and was > not > > > > disappointed) and at least one strong opinion from the Maven core > team. > > > As > > > > to why I put overrides in the management section in the first place: > > > simply > > > > because I saw overrides as a management subject. > > > > > > > > About using the existing dependency tag to define replacements: I > tried > > > > that (in a way, I still used a different tag name though). The issue > I > > > have > > > > with it is that the dependency tag can also take version, exclusions, > > > > optional, etc. and I want that to be in the > > > > /project/dependencyManagement/dependencies section. I'm applying the > > > > separation of concerns principle here: overrides should simply map > > > artifact > > > > coordinates whereas managed dependencies are all about the right > > versions > > > > and such. Or maybe the managed dependencies should also provide the > > > > override information? The entire existing implementation can still be > > > > changed with little effort. > > > > > > > > I also thought about allowing 0..n overrides for one original, but I > > > > decided to make it a 1:1 mapping. Let me explain: First, I think it > is > > > > currently not possible to have lists in POMs without a wrapping > > element. > > > > One would have to write: > > > > > > > > <!-- Simplified code for brevity --> > > > > <dependencyOverrides> > > > > <dependencyOverride> > > > > <original/> > > > > <dependencies> > > > > <dependency/> > > > > ... > > > > </dependencies> > > > > </dependencyOverride> > > > > </dependencyOverrides> > > > > > > > > Please correct me on this if I'm wrong. Second, I think most of the > > time > > > > people will be having 1:1 mappings anyway and with that in mind, > having > > > the > > > > need to use lists which require a wrapping element would bloat a POM. > > > > > > > > Long story short, your first point is up for discussion. If more > people > > > > want overrides located elsewhere, then that's fine by me. Regarding > > your > > > > second point, I think the current approach is good and people would > > have > > > to > > > > provide strong arguments to convince me of a different approach. > > > > > > > > Again, thanks for the feedback, it's really appreciated and if you > have > > > > more, please let me know. > > > > > > > > Kind regards, > > > > Enno > > > > > > > > ________________________________ > > > > From: Delany <delany.middle...@gmail.com> > > > > Sent: Sunday, November 21, 2021 4:46 AM > > > > To: Maven Developers List <dev@maven.apache.org> > > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > Hi Enno, > > > > > > > > 2 things. I'd want to emphasise that the resolution of dependency > > > > management info and the dependency overrides (more like a reactor > > > > management concern) are independent of one another. Can achieve by > > > > promoting the tag to project. > > > > > > > > Then why not use the existing dependency tag to define the > > > replacement(s). > > > > Accept 0, 1 or many. > > > > > > > > ... > > > > <groupId>a</groupId> > > > > <artifactId>a</artifactId> > > > > <dependencyOverrides> > > > > <dependencyOverride> > > > > <original> > > > > <groupId>y</groupId> > > > > <artifactId>y</artifactId> > > > > </original> > > > > <dependency> > > > > <groupId>z</groupId> > > > > <artifactId>z</artifactId> > > > > </dependency> > > > > <dependency> > > > > <groupId>q</groupId> > > > > <artifactId>q</artifactId> > > > > </dependency> > > > > </dependencyOverride> > > > > </dependencyOverrides> > > > > <dependencies> > > > > <dependency> > > > > <groupId>w</groupId> > > > > <artifactId>w</artifactId> > > > > </dependency> > > > > <dependency> > > > > <groupId>x</groupId> > > > > <artifactId>x</artifactId> > > > > </dependency> > > > > </dependencies> > > > > ... > > > > > > > > > > > > Regards, > > > > Delany > > > > > > > > > > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke < > > enno.thiel...@holisticon.de > > > > > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > it's been a while and I've made some progress regarding > > > > > overrides/replacements and wanted to share the current state. > > > > > > > > > > What's implemented/changed: > > > > > > > > > > * The POM version has been upgraded to 4.1.0 and will accept > > > > > /project/dependencyManagement/dependencyOverrides which in turn can > > > take > > > > > the coordinates of original and overriding artifacts. > > > > > * Overrides can be declared on any POM level in a hierarchy > POMs > > > > (i.e. > > > > > parents and children. > > > > > * Overrides can be imported from other POMs using the existing > > > > > `import` scope for POMs in the dependencyManagement section. > > > > > * If the same original artifact is overridden on different > > levels, > > > > the > > > > > "most downstream" wins. > > > > > * An override *must* be accompanied by an entry in the > > > > > dependencyManagement section. Maven generates an error and halts, > if > > > > that's > > > > > not the case. > > > > > * If an override is declared and consumed in the same effective > > > POM, > > > > > Maven generates a warning that the user should use the overriding > > > > artifact > > > > > instead of the original artifact. > > > > > * The dependencies of an effective POM remain untouched. > > Overrides > > > > are > > > > > declared in POMs, but the act of overriding is implemented in > > > > > maven-resolver. > > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, > because > > > > > interfaces needed additions. While some might consider this to be a > > > minor > > > > > change, I consider this to be a major change, because the > interfaces > > > are > > > > > not (and cannot be, yet) sealed. > > > > > * It is possible to override overrides of transitive > > dependencies. > > > In > > > > > other words, it is possible to override overrides of POMs of > > > > dependencies. > > > > > > > > > > While working on this I thought about names for > > overrides/replacements. > > > > > I'm still open to suggestions and pretty much undecided. Another > name > > > > that > > > > > popped into my head is `dropinReplacements`, because it makes the > > > intent > > > > > very clear. > > > > > > > > > > For those of you who are interested, here are the links to the code > > > again > > > > > (so it's just one click away): > > > > > > > > > > * > > > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530 > > > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530 > > > > > * > https://github.com/strohmattenverleger/maven-MNG-4530-example > > > > > > > > > > Also, I've rebased my changes onto master very recently. > > > > > > > > > > And here's the proposal itself: > > > > > > > > > > > > > > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md > > > > > > > > > > If you find the time to look, please let me know what you think and > > > what > > > > > you think is missing. > > > > > > > > > > Kind regards > > > > > Enno > > > > > > > > > > ________________________________ > > > > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > > > > Sent: Sunday, September 5, 2021 8:34 AM > > > > > To: Maven Developers List <dev@maven.apache.org> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > > > A few notes on the proposal: > > > > > > > > > > > > > > > - Leave a dependency graph virtually untouched. > > > > > Only change/override nodes in place. Don't exclude dependencies > > and > > > > > include new ones on a different level in the graph. > > > > > > > > > > Think, whatever it means, served dependencies in mojo shouldnt have > > to > > > > rely > > > > > on this new section using getXArtifact or dependency visitor. No > real > > > > good > > > > > reason to break everyone there. > > > > > > > > > > A not used override must break the build (it is an unexpected bug > and > > > > would > > > > > make the dev life hard otherwise). I perfectly see that it will > break > > > > > building a submodule in several cases but otherwise the section > will > > > > become > > > > > unmanageable with time (see hibernate or cxf example) and since you > > > loose > > > > > the dependency relationship with this option compared to > exclusions, > > it > > > > way > > > > > too much work to maintain it in practise. (This is why I think it > > > > shouldnt > > > > > be done this way but very worse case at dependency level giving > hints > > > for > > > > > overrides and not elsewhere, mixed with dependency managementnit is > > > > trivial > > > > > to handle and maintain then). > > > > > > > > > > Pom rewriter must handle this section by dropping it and replacing > it > > > by > > > > > exludes to keep compatibility with 3rd party resolvers > (deployment). > > > > > > > > > > Overall, I still think it would be neat to see it as an extension > for > > > > maven > > > > > 3.8.2 or 4 to be testable and validate design choices and actual > > usage > > > on > > > > > real dependencies compared to current option. > > > > > > > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke < > > > enno.thiel...@holisticon.de > > > > > > > > > > a > > > > > écrit : > > > > > > > > > > > Hello again, > > > > > > > > > > > > I tried to create a proposal in/under > > > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567 > > > > > , > > > > > > but I'm not allowed to, which makes sense since I'm new to the > > wiki, > > > > so I > > > > > > committed a proposal to my fork: > > > > > > > > > > > > > > > > > > > > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md > > > > > > > > > > > > The current version probably still contains errors and misses > > details > > > > but > > > > > > I imo they need to be worked out in a group effort. > > > > > > > > > > > > Some feedback/comments would be appreciated. > > > > > > > > > > > > Maybe you could create a proposal page in your wiki and grant me > > edit > > > > > > rights (user eth)? > > > > > > > > > > > > Kind regards > > > > > > Enno > > > > > > > > > > > > ________________________________ > > > > > > From: Enno Thieleke <enno.thiel...@holisticon.de> > > > > > > Sent: Thursday, August 26, 2021 11:59 AM > > > > > > To: Maven Developers List <dev@maven.apache.org> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > > > > > Hi Michael, > > > > > > > > > > > > I'll take this as a "go ahead, if it's good we'll accept it". > > > > > > > > > > > > Just a few more questions before I start. > > > > > > > > > > > > For the issue: Would reopening > > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would > > you > > > > like > > > > > > to see a new one? > > > > > > > > > > > > Where do I create the proposal? > > > > > > > > > > > > What should be created first, the issue or the proposal? I'm > > asking, > > > > > > because in the proposal we'd work out the details and after > that's > > > > done, > > > > > > that's where the issue becomes relevant (no issue, no code > > changes). > > > At > > > > > > least that's how I'm used to implementing changes like this. I > > don't > > > > want > > > > > > to have created unnecessary noise in your issue system, if - for > > some > > > > > > unknown eventuality - the proposal doesn't get your approval. > > > > > > > > > > > > Is it ok to use one issue for changes in both projects, Maven and > > > > > > maven-resolver? > > > > > > > > > > > > Kind regards > > > > > > Enno > > > > > > ________________________________ > > > > > > From: Michael Osipov <micha...@apache.org> > > > > > > Sent: Wednesday, August 25, 2021 9:01 PM > > > > > > To: dev@maven.apache.org <dev@maven.apache.org> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > > > > > Am 2021-08-25 um 20:51 schrieb Enno Thieleke: > > > > > > > Hello again, > > > > > > > > > > > > > > some days have passed and I didn't want to distract you people > > from > > > > > > releasing the new version of Maven, but now that it's done, I'm > > > getting > > > > > > back to this topic. > > > > > > > > > > > > > > I'm asking for the opinion of the Maven PMC and committers > > > regarding > > > > > > this feature. I'd like to see some sort of dependency > > > > > override/replacement > > > > > > mechanism. One that's powerful, yet easy to use, which doesn't > > > require > > > > > > boilerplate XML and which leaves the dependency graph virtually > > > > untouched > > > > > > (by that I mean the shape of the graph remains the same, unless > > > > > additional > > > > > > transitive dependencies are brought into play by > > > > overrides/replacements). > > > > > > > > > > > > > > Please let me know what you people think of such a feature. > > Maybe a > > > > > vote > > > > > > is in order, but I'm not sure and I wouldn't know how to call for > > one > > > > > > properly here. Please tell me how to proceed. I'm only willing to > > > > commit > > > > > > more time to this, if I have an ok from you that it'll be merged > > once > > > > it > > > > > > meets the quality standards of the Maven project. > > > > > > > > > > > > As I said previously, this perfectly makes sense, but having this > > in > > > > > > Core means that someone needs to create an issue, proposal and a > > PR. > > > > > > Consider that no one of us is getting paid on this, so free time > > > only. > > > > > > Unless it comes from the community, I see little chances to have > > this > > > > > soon. > > > > > > > > > > > > Michael > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > >
