Hi, Hervé, thanks for the information.
1. Yes, Dependency-Overrides.md is up-to-date. I've changed one detail though, but it doesn't affect the big picture, it just makes things clearer: overrides can now declare a version (which makes corresponding managed dependencies optional to reduce XML code). 2. I've implemented all the stuff I suggested in Dependency-Overrides.md already. A working example can be found at g...@github.com:strohmattenverleger/maven-MNG-4530-example.git Just build g...@github.com:strohmattenverleger/maven-resolver.git and g...@github.com:strohmattenverleger/maven.git first. 3. After reading your article I can now understand why it would/could be a bad idea to simply update the POM version from 4.0 to, say, 4.1. A Maven 3 installation would be obsolete if there was a single POM in a graph that's "too new". Let's imagine updating the POM of Guava or SLF4J to something like 4.1 for a second. Boom. To be honest: I wouldn't mind being forced to update to a newer Maven version in such a case. The world keeps turning after all. :) But if it can be avoided with good measures, then that approach should be preferred. And I think the build vs. consumer POM approach is promising (no plugin configurations and such in consumer POMs), which brings me to your next point. 4. I'm having trouble imagining a way to generate a consumer POM (4.0) from my build POM (i.e. a POM with overrides). Yes, one could juggle with excludes (again), but the idea of dependency overrides is to modify certain nodes in a dependency graph without the need for exclusions. This is why I went for a minor update of the POM schema in the first place. I would like overrides to be transparent and concise. Unfortunately I can't think of a way how to implement this feature for older Maven versions without "them knowing what they are dealing with", if we are talking about proper overrides/replacements, not just exclusions and additional dependencies. Not very satisfying, I know. Do you have an idea? I'm open to suggestions. Regarding MNG-6772: Interesting. I never experienced this issue myself, but I agree with your expectation in https://issues.apache.org/jira/browse/MNG-6772?focusedCommentId=17310052&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310052 Since there's no corresponding branch in https://github.com/apache/maven do you need someone to give a solution to this issue another try before we get our hands dirty with other stuff? Did I unterstand you correctly? Regards, Enno ________________________________ From: Hervé BOUTEMY <herve.bout...@free.fr> Sent: Wednesday, December 22, 2021 8:42 AM To: Maven Developers List <dev@maven.apache.org> Subject: Re: Fw: Request for Enhancement: Dependency Overrides I forgot: last but not least we have consistency issues with parent POM and dependencyManagement POM import downloads when repositories are defined in projects pom.xml see https://issues.apache.org/jira/browse/MNG-6772 and linked issues while working on all this dependencies management, it would be useful to fix this issue that is blocking other improvements: - definition of central in settings.xml https://issues.apache.org/jira/browse/MNG-4645 - pluginManagement import https://issues.apache.org/jira/browse/MNG-5588 = I don't want to copy/paste a 2nd time the buggy code from dependencyManagement import as it was copied from parent resolution... Regards, Hervé Le mercredi 22 décembre 2021, 08:37:08 CET Hervé BOUTEMY a écrit : > my own quick opinion: > > 1. I did not review the full email thread, so is > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overr > ides.md still the current state of the idea? > > 2. can you add concrete examples, please? > > 3. given the impact, I fear this may be for Maven 5: we clearly need to > focus on releasing Maven 4 first > https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html > > 4. as part of the build vs consumer pom approach, do you think a consumer > pom can be generated from your build pom? > > Regards, > > Hervé > > Le lundi 20 décembre 2021, 21:25:39 CET Enno Thieleke 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-performa > > > nc > > > e > > > > > > > > > > > > > > > > > > > > > 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-Ov > > > er > > > rides.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-Ov > > > er > > > rides.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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
