Re: Fw: Request for Enhancement: Dependency Overrides
Hi, folks, hope you're all well? After some time, I finally was able to get back to this topic. I've realized something. Maven 3 (and 4, or at least what's on the master branch) are hard wired to one specific model version. I'm deducing this by the fact that the model generation via Modello uses one model version (4.0.0) and also doesn't use versioned packages. So, whenever Maven builds/writes a POM for you, you get that particular model version and its corresponding namespace and schema attributes in the root element. Reading a POM though doesn't require anything special (sure, the XML must conform to the schema, but the element "modelVersion" can be anything until it is verified by Maven). The namespace and schema attributes aren't even taken into account afaict. Why am I bringing this up? I'm still in for a model change and if I want to successfully introduce one, it would need to be a minor change (non-breaking), not a major change. So, adding new XML elements, like in my case or in cases of different Maven issues (e.g. global exclusions), would be ok. Removing some element or attribute on the other hand would not be ok. And how would minor changes be ok? It would enable us to modify Maven 3 to be able to handle "newer" model versions simply by ignoring unknown XML elements and attributes. One could think of such newer XML elements or attributes as not supported by Maven 3. A warning in the build log could inform the user of such situations, because build results might or might not be as expected. So, the idea is that the Maven model could evolve in minor versions and for users to fully benefit from it, they would need to "keep up" with the Maven installation, which they should anyway for security and performance updates as well as bug fixes. And to have a "nice" namespace and schema we could change http://maven.[...]/POM/4.0.0 to http://maven.[...]/POM/4.x.x. Also: Whenever Maven generates/writes a POM, it could try to use the lowest minor version possible for compatibility reasons, depending on what functionality a POM uses. No need to write a 4.1.0 if no "advanced" feature is being used. I know all of this is only relevant to Maven 3 and 4. Maven 5 will have a completely different approach when it comes to POMs and additions to the model might need to be dealt with differently. I've asked myself a few times by now: Can I implement this dependency overrides/replacements feature without changing the model? It's difficult. I don't think extensions would work. For this feature to work as I intend it to, the Maven Resolver needs to be changed to honor overrides/replacements and overrides need to be passed on to it when Maven runs, which is why I think it needs to be a core feature. A different approach would be to introduce a "Maven reserved artifact" for dependency overrides. A POM accompanying (XML) file which needs to contain pretty much what I suggested to add to the existing model. Previous Maven versions wouldn't be able to work with such files, because they are not aware of them, but one wouldn't see any build warnings like I suggested above. Sorry for the very, very long post, but I really want to get this feature into Maven and I need more brain power (yours to be precise) to do so. Please share your thoughts. Kind regards, Enno P.S. Just as a reminder: Pretty much all of this is implemented already and also rebased onto the latest Maven and Maven Resolver master branches. You can find the URLs to all repositories (Maven, Maven Resolver and some examples) in my previous mails. From: Enno Thieleke Sent: Sunday, December 26, 2021 8:47 PM To: Maven Developers List Subject: Re: Fw: Request for Enhancement: Dependency Overrides 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
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Fwiw:
Romain, I think you're exaggerating. The answer is, like in most cases: "it
depends".
Most people, we're most likely talking 95-99% here, will happily use JDK 17
with Maven 4.
Some people might need to compile for lower sources and targets, but running
tests for those builds in JDK 17 instead of, let's say 11, _will suffice in
most cases_.
Yes, there will be edge cases where people will be forced to use different JDKs
at least for tests, some even for builds. But that's possible, so they won't
get left behind.
Regarding mvnd: It's not a silver bullet. It never was and it never will be.
Whenever a build spawns new JVMs (for tests or other tasks), it doesn't benefit
from mvnd anymore (in as much as it would without spawning new JVMs).
To not use the latest (LTS) JDK in order to "better" support the 1-5% of the
Maven users, who're still using obsolete JVMs (I'm obviously referring to
Karl's assumption, which I agree with), would be a kick in the teeth of all
Maven developers, who finally want to embrace the present (not even the future).
Long story short, +1 for JDK 17 as minimum for Maven 4.
Kind regards,
Enno
From: Romain Manni-Bucau
Sent: Saturday, July 23, 2022 6:55 PM
To: Maven Developers List
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell a
écrit :
> No, 2 JDKs are not required by default. Only if you use --release={<17} and
> don't trust running tests on 17 are the same as running tests on 8.
> Yes, there are changes (certificates, XML libs, rhino, etc).
>
As explained it means you dont write a single test or dont care of the test
results so yes it needs 2 jdk.
> So, for most projects that's probably not needed. For those who think it is
> needed, I don't have a lot of pity. But it will be a requirement for quite
> a few commercial projects, like Containers (JavaEE, as they will need to be
> Java 8 as long as 2030ish due to extended support contracts).
>
> That said, I'm still thinking Java 17 will be a sane default.
>
>
> On Sat, 23 Jul 2022, 10:50 Delany, wrote:
>
> > Using mvnd with toolchains doesn't improve the situation, in fact
> > toolchains seem to invalidate any benefit of using mvnd.
> > Even if this was resolved, is it fair to require mvnd?
> > Delany
> >
> >
> > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt wrote:
> >
> > > Is that due to cold starting the JVM each time?
> > >
> > > I wonder if mvnd supports toolchains effectively? Or if that could be
> an
> > > avenue to try.
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > Wilson,
> > > Porcupine Tree
> > >
> > > On 23/07/2022 at 8:13:23 PM, Delany
> wrote:
> > >
> > > > I tried toolchains but dropped it because of the exorbitant
> performance
> > > > costs.
> > > > A multi-module build that normally built in 3:50 took 10:34, and
> that's
> > > > with toolchaining only maven-compiler-plugin.
> > > >
> > > >
> > > >
> > >
> >
>
Re: Fw: Request for Enhancement: Dependency Overrides
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=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 Sent: Wednesday, December 22, 2021 8:42 AM To: Maven Developers List 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 > > Sent: Friday, December 3, 2021 10:54 AM > > To: Maven Developers List > > 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 &g
Fw: Request for Enhancement: Dependency Overrides
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 Sent: Friday, December 3, 2021 10:54 AM To: Maven Developers List 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: ... import ... 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 Sent: Monday, November 22, 2021 2:33 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le lun. 22 nov. 2021 à 14:15, Enno Thieleke 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 no
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: ... import ... 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 Sent: Monday, November 22, 2021 2:33 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le lun. 22 nov. 2021 à 14:15, Enno Thieleke 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 d
Re: Request for Enhancement: Dependency Overrides
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 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. 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 Sent: Monday, November 22, 2021 11:00 AM To: Maven Developers List 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 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 a
Re: Request for Enhancement: Dependency Overrides
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: ... 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 Sent: Sunday, November 21, 2021 4:46 AM To: Maven Developers List 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. ... a a y y z z q q w w x x ... Regards, Delany On Sun, 21 Nov 2021 at 02:05, Enno Thieleke 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/MN
Re: Request for Enhancement: Dependency Overrides
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 Sent: Sunday, September 5, 2021 8:34 AM To: Maven Developers List 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 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 > Sent: Thursday, August 26, 2021 11:59 AM > To: Maven Developers List > Subject: Re: Request for Enhancement: Dependency Overrides > > Hi Michael, > > I'll take this as a "go ahead, if it's good
Re: Removing IRC channel mentions from official website documentation
As one of the new guys, I can confirm that IRC is misleading and confusing. I totally missed any topic regarding the "we moved to slack" part. Could've been a bad IRC client, could've been me, not sure. I agree with Bernd: New people would very much like to find slack information on the website, even though access is restricted. And yes, mentioning who gets access and how would help a great deal, I think, albeit just for clarification. Kind regards Enno From: Bernd Eckenfels Sent: Wednesday, September 8, 2021 10:30 PM To: Maven Developers List Subject: Re: Removing IRC channel mentions from official website documentation Thanks for bringing this to our attention and I agree we should remove the irc channel in this case. Not sure about the slack since I don’t use it, but the website is not only for the public, it’s also the primary source for committers (but if we add the slack we certainly need to mention who gets access and how) On what URLs you saw the irc channel? Gruss Bernd -- http://bernd.eckenfels.net Von: Dawid Pura Gesendet: Wednesday, September 8, 2021 10:16:27 PM An: dev@maven.apache.org Betreff: Removing IRC channel mentions from official website documentation Hello all, I have noticed it's misleading for new contributors to find out the proper communication channel for this project. The documentation says there is an IRC channel which topic says "we moved to Slack". Then, it takes some time to figure out a newcomer cannot get in, since she has to be invited by actual commiters. I think I can remove any mention of IRC channel from maven-site, as this has been deprecated comms channel, right? I am asking the more subtle question, should the Slack channel be mentioned instead, or there is no reason to mention it in public docs as it's not reachable by the public. this is my very first e-mail on this mailing list and mailing lists in Apache in general, so please share any feedback that comes to your mind :). All the best, Dawid Pura
Re: Request for Enhancement: Dependency Overrides
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 Sent: Thursday, August 26, 2021 11:59 AM To: Maven Developers List 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 Sent: Wednesday, August 25, 2021 9:01 PM To: 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
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 Sent: Wednesday, August 25, 2021 9:01 PM To: 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
Re: Request for Enhancement: Dependency Overrides
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. Kind regards Enno As a reminder, here's my PoC: 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 parent/root POM contains an override example) From: Romain Manni-Bucau Sent: Sunday, August 15, 2021 8:04 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le dim. 15 août 2021 à 18:19, Enno Thieleke 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
Re: Request for Enhancement: Dependency Overrides
s are in the POM, not in Hibernate (as far as the graph is concerned). 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. 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. From: Romain Manni-Bucau Sent: Sunday, August 15, 2021 3:07 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le dim. 15 août 2021 à 14:29, Enno Thieleke 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
Re: Request for Enhancement: Dependency Overrides
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. 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. 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". 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. 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. 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. 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. 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. 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. 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. From: Romain Manni-Bucau Sent: Sunday, August 15, 2021 8:35 AM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le sam. 14 août 2021 à 22:21, Enno Thieleke 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 i
Re: Request for Enhancement: Dependency Overrides
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. The common solution is cumbersome and verbose. Why somebody would prefer it over a more concise XML element is beyond me. You say it brings drawbacks. What are they? Please elaborate. [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 Sent: Saturday, August 14, 2021 8:14 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le sam. 14 août 2021 à 18:56, Enno Thieleke 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 > Sent: Saturday, August 14, 2021 5:08 PM > To: Maven Developers List > Subject: Re: Request for Enhancement: Dependency Overrides > > Le sam. 14 août 2021 à 16:52, Enno Thieleke > 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 man
Re: Request for Enhancement: Dependency Overrides
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. 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). 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". 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. From: Romain Manni-Bucau Sent: Saturday, August 14, 2021 5:08 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le sam. 14 août 2021 à 16:52, Enno Thieleke 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 > Sent: Saturday, August 14, 2021 4:31 PM > To: Maven Developers List > 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 > Gesendet: Saturday, August 14, 2021 3:38:53 PM > An: Maven Developers List > 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 &g
Re: Request for Enhancement: Dependency Overrides
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. From: Bernd Eckenfels Sent: Saturday, August 14, 2021 4:31 PM To: Maven Developers List 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 Gesendet: Saturday, August 14, 2021 3:38:53 PM An: Maven Developers List 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 Sent: Saturday, August 14, 2021 2:28 PM To: Maven Developers List 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 Gesendet: Saturday, August 14, 2021 1:24:26 PM An: Maven Developers List 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 Sent: Saturd
Re: Request for Enhancement: Dependency Overrides
Could you please elaborate on why a registry would be necessary? What kind of registry are we talking about (what would its purpose be)? Profiles should not be an issue since they should be merged into the model at a very early stage, even before dependency management kicks in, right? Hence there's no or little development needed here. If a profile contains overrides, they'd be merged into the model as if they were there from the start (at least that's how I imagine it would be). From: Romain Manni-Bucau Sent: Saturday, August 14, 2021 2:08 PM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides Le sam. 14 août 2021 à 13:24, Enno Thieleke a écrit : > So, you're saying that I can replace artifact coordinates with > dependencyManagement.dependencies already? I'm not talking about versions, > scopes and exclusions, I'm talking about groupIds and artifactIds. My idea > is, simply put, if artifact commons-logging:commons-logging is found, > org.slf4j:jcl-over-slf4j is used instead. Or if artifact > org.hibernate.javax.persistence:hibernate-jpa-2.2-api is found, > jakarta.persistence:jakarta.persistence-api is used instead. I don't think > that this is possible with the current version of Maven. If it is, please > share a link to the docs covering this feature. > I see This clearly sounds like an extension scope since it will quickly need a registry and profiles as feature and I dont see it fitting maven (would make it too complex). Without these features it is almost useless since dependency management or a pivot pom give you enough control to enforce the artifact you want. > Feel free to look at the example I provided. I feel it makes my idea more > comprehensible. > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530 > https://github.com/strohmattenverleger/maven/tree/MNG-4530 (requires the > changes I made to maven-resolver) > https://github.com/strohmattenverleger/maven-MNG-4530-example (the > "magic" happens in the parent/root POM) > > Also, I don't think implementing this as an extension is the right thing > to do. If it were to be fully implemented, it'd have to be a core feature > of Maven and the Maven Resolver. This way the entire user base of Maven > would benefit from it. > Most of maven consumers dont use maven resolver so I dont agree with that last part and is one of the multiples reasons I think it must not be a core feature (added to the previous mentionned facts). > From: Romain Manni-Bucau > Sent: Saturday, August 14, 2021 8:55 AM > To: Maven Developers List > 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 > 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 questio
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 Sent: Saturday, August 14, 2021 2:28 PM To: Maven Developers List 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 Gesendet: Saturday, August 14, 2021 1:24:26 PM An: Maven Developers List 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 Sent: Saturday, August 14, 2021 8:55 AM To: Maven Developers List 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 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 r
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 Sent: Saturday, August 14, 2021 8:55 AM To: Maven Developers List 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 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 > Sent: Friday, August 13, 2021 2:41 PM > To: Maven Developers List > 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://w
Re: Request for Enhancement: Dependency Overrides
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 Sent: Friday, August 13, 2021 2:41 PM To: Maven Developers List 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 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 manua
Re: Request for Enhancement: Dependency Overrides
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 Sent: Wednesday, August 11, 2021 4:31 PM To: 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
Request for Enhancement: Dependency Overrides
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. Kind regards, Enno
