You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Enno Thieleke <En...@holisticon.de> on 2021/09/04 21:21:04 UTC
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 <En...@holisticon.de>
Sent: Thursday, August 26, 2021 11:59 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
Hi Michael,
I'll take this as a "go ahead, if it's good we'll accept it".
Just a few more questions before I start.
For the issue: Would reopening https://issues.apache.org/jira/browse/MNG-4530 suffice or would you like to see a new one?
Where do I create the proposal?
What should be created first, the issue or the proposal? I'm asking, because in the proposal we'd work out the details and after that's done, that's where the issue becomes relevant (no issue, no code changes). At least that's how I'm used to implementing changes like this. I don't want to have created unnecessary noise in your issue system, if - for some unknown eventuality - the proposal doesn't get your approval.
Is it ok to use one issue for changes in both projects, Maven and maven-resolver?
Kind regards
Enno
________________________________
From: Michael Osipov <mi...@apache.org>
Sent: Wednesday, August 25, 2021 9:01 PM
To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Vscode too but not idea nlr netbeans, this is where we should agree and
request enhancement if we want to enable new model versions without
awaiting integrations coming after releases - so too late for adoption, the
egg or chicken pb.
Le dim. 2 oct. 2022 à 16:58, Hannes Wellmann <we...@gmx.net> a
écrit :
>
> > Options I see is to either do the uodate since IDE are open source but it
> > requires more man power OR provide a language server and let IDE do their
> > integration with it, this option can need some discussion with
> > idea/netbeans/eclipse maven integrators but sounds like a good compromise
> > for everyone since we dont need IDE knowledge and even
> mvnd+cache-extension
> > could leverage it at some point to support multiple versions and
> projects.
>
> In case you are interested, the Eclipse-Maven integration already uses the
> 'lemminx-maven' [1] Language-Server extension based on lemminx, which is a
> LS-protocol implementation for XML.
>
> [1] - https://github.com/eclipse/lemminx-maven
> [2] - https://github.com/eclipse/lemminx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Aw: Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Hannes Wellmann <we...@gmx.net>.
> Options I see is to either do the uodate since IDE are open source but it
> requires more man power OR provide a language server and let IDE do their
> integration with it, this option can need some discussion with
> idea/netbeans/eclipse maven integrators but sounds like a good compromise
> for everyone since we dont need IDE knowledge and even mvnd+cache-extension
> could leverage it at some point to support multiple versions and projects.
In case you are interested, the Eclipse-Maven integration already uses the 'lemminx-maven' [1] Language-Server extension based on lemminx, which is a LS-protocol implementation for XML.
[1] - https://github.com/eclipse/lemminx-maven
[2] - https://github.com/eclipse/lemminx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Enno,
Just to clarify: the ouput pom (on release) mudt be 4.0.0 and all > 4.0.0
features must be resolved to comply to ensure the compatibility with 3rd
parties.
The produced pom flavor should always be 4.0.0 whereas the consumed one can
evolve when very relevant.
My main concern with model evolution is it breaks IDE and depending how
impacting it is, not sure they catch up fast enough (at least idea is still
the most used ide today and they dont rely on maven to do so) so at the end
we can need to think more about ide.
Options I see is to either do the uodate since IDE are open source but it
requires more man power OR provide a language server and let IDE do their
integration with it, this option can need some discussion with
idea/netbeans/eclipse maven integrators but sounds like a good compromise
for everyone since we dont need IDE knowledge and even mvnd+cache-extension
could leverage it at some point to support multiple versions and projects.
Le sam. 1 oct. 2022 à 20:41, Enno Thieleke <En...@holisticon.de> a
écrit :
> 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 <En...@holisticon.de>
> Sent: Sunday, December 26, 2021 8:47 PM
> To: Maven Developers List <de...@maven.apache.org>
> 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
> git@github.com:strohmattenverleger/maven-MNG-4530-example.git
> Just build git@github.com:strohmattenverleger/maven-resolver.git and
> git@github.com:strohmattenverleger/maven.git first.
> 3. After reading your article I can now understand why it would/could
> be a bad idea to simply update the POM version from 4.0 to, say, 4.1. A
> Maven 3 installation would be obsolete if there was a single POM in a graph
> that's "too new". Let's imagine updating the POM of Guava or SLF4J to
> something like 4.1 for a second. Boom.
> To be honest: I wouldn't mind being forced to update to a newer Maven
> version in such a case. The world keeps turning after all. :) But if it can
> be avoided with good measures, then that approach should be preferred. And
> I think the build vs. consumer POM approach is promising (no plugin
> configurations and such in consumer POMs), which brings me to your next
> point.
> 4. I'm having trouble imagining a way to generate a consumer POM (4.0)
> from my build POM (i.e. a POM with overrides). Yes, one could juggle with
> excludes (again), but the idea of dependency overrides is to modify certain
> nodes in a dependency graph without the need for exclusions. This is why I
> went for a minor update of the POM schema in the first place. I would like
> overrides to be transparent and concise.
> Unfortunately I can't think of a way how to implement this feature for
> older Maven versions without "them knowing what they are dealing with", if
> we are talking about proper overrides/replacements, not just exclusions and
> additional dependencies. Not very satisfying, I know. Do you have an idea?
> I'm open to suggestions.
>
> Regarding MNG-6772: Interesting. I never experienced this issue myself,
> but I agree with your expectation in
> https://issues.apache.org/jira/browse/MNG-6772?focusedCommentId=17310052&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310052
> Since there's no corresponding branch in https://github.com/apache/maven
> do you need someone to give a solution to this issue another try before we
> get our hands dirty with other stuff? Did I unterstand you correctly?
>
> Regards,
> Enno
>
> ________________________________
> From: Hervé BOUTEMY <he...@free.fr>
> Sent: Wednesday, December 22, 2021 8:42 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Fw: Request for Enhancement: Dependency Overrides
>
> I forgot: last but not least
>
> we have consistency issues with parent POM and dependencyManagement POM
> import downloads when repositories are defined in projects pom.xml
> see https://issues.apache.org/jira/browse/MNG-6772 and linked issues
>
> while working on all this dependencies management, it would be useful to
> fix this issue that is blocking other improvements:
> - definition of central in settings.xml
> https://issues.apache.org/jira/browse/MNG-4645
> - pluginManagement import https://issues.apache.org/jira/browse/MNG-5588
> = I don't want to copy/paste a 2nd time the buggy code from
> dependencyManagement import as it was copied from parent resolution...
>
> Regards,
>
> Hervé
>
> Le mercredi 22 décembre 2021, 08:37:08 CET Hervé BOUTEMY a écrit :
> > my own quick opinion:
> >
> > 1. I did not review the full email thread, so is
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overr
> > ides.md still the current state of the idea?
> >
> > 2. can you add concrete examples, please?
> >
> > 3. given the impact, I fear this may be for Maven 5: we clearly need to
> > focus on releasing Maven 4 first
> > https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
> >
> > 4. as part of the build vs consumer pom approach, do you think a consumer
> > pom can be generated from your build pom?
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 20 décembre 2021, 21:25:39 CET Enno Thieleke a écrit :
> > > Hello again,
> > >
> > > judging by the increased traffic in this mailing list some of you seem
> to
> > > be on vacation. That's nice. I was hoping that this might be a good
> time
> > > to ask for your opinion again about what I wrote a couple of weeks ago?
> > >
> > > Kind regards
> > > Enno
> > >
> > > ________________________________
> > > From: Enno Thieleke <En...@holisticon.de>
> > > Sent: Friday, December 3, 2021 10:54 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > Hi,
> > >
> > > concerning the request to change the override XML element to a
> > > fully-fledged dependency, thus removing the need for accompanying
> managed
> > > dependencies...
> > >
> > > tl;dr
> > > I would add a version attribute, nothing more, to the override XML
> > > element.
> > > The rest would remain unchanged.
> > >
> > > Full version:
> > >
> > > If I turned the override XML element into a fully-fledged dependency,
> > > should we support properties such as `scope` and `optional`? In my
> > > opinion we shouldn't, because that's still subject to original
> dependency
> > > definitions, not overrides. If people want to change the scope or add
> > > exclusions, they should stick to dependency management. That's what
> it's
> > > there for.
> > I think
> >
> > > it's enough to just add a version child-element to the current override
> > > XML
> > > element. That would remove the need for accompanying managed
> dependencies
> > > for just versions and in many simple cases that'd suffice, wouldn't you
> > > agree? I think we should draw the line here between changing artifact
> > > coordinates, a special kind of dependency management, and managing
> other
> > > dependency properties -> separation of concerns. Suppose I added a
> version
> > > child-element, I'd still have concerns about moving
> dependencyOverrides up
> > > one level so that it would be a sibling of dependencyManagement.
> Imagine I
> > > moved dependencyOverrides up one level. How would we import them
> properly?
> > > Currently importing a POM imports both: managed dependencies as well as
> > > overrides and I think that wouldn't be the right approach anymore.
> Would
> > > special import XML elements do the trick? Such as this:
> > > <dependencyManagement>
> > >
> > > <dependencies>
> > >
> > > <dependency>
> > >
> > > ...
> > > <scope>import</scope> <!-- Imports managed dependencies -->
> > >
> > > </dependency>
> > >
> > > </dependencies>
> > >
> > > </dependencyManagement>
> > > <dependencyOverrides>
> > >
> > > <imports>
> > >
> > > <import> <!-- Imports overrides; the packaging of the import MUST
> be
> > > pom
> > >
> > > -->
> >
> > <groupId/>
> >
> > > <artifactId/>
> > > <version/>
> > >
> > > </import>
> > >
> > > </imports>
> > > ...
> > >
> > > </dependencyOverrides>
> > >
> > > To be honest: I think that'd suck. Another way would be to introduce a
> new
> > > special purpose scope, but I think the existing special purpose scope
> > > "import" is perfect: it's meant to import dependency management
> > > information
> > > from different POMs and since overrides affect dependencies in the
> sense
> > > that they manage dependency coordinates, we're still talking about
> > > dependency management.
> > >
> > > Please let me know what you think.
> > >
> > > Kind regards
> > > Enno
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Monday, November 22, 2021 2:33 PM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <
> Enno.Thieleke@holisticon.de>
> > > a
> > >
> > > écrit :
> > > > Hello,
> > > >
> > > >
> > > >
> > > > @Delany, regarding 1 and 2: If I added all the other elements of the
> > > > dependency tag, I would have to apply dependency management anyway if
> > > > present (and I played around with it for a bit), but I see your
> point.
> > > > Maybe using the dependency tag (I'd still name it override though) is
> > > > "good
> >
> > enough" for small projects/POMs. I will throw a bit of time at it
> >
> > > > and check for "bad" implications.
> > > >
> > > >
> > > >
> > > > Making the override tag optional to have some sort of global
> exclusion
> > > > mechanism is out of scope. Let me explain: When dependency management
> > > > comes
> >
> > into play (in maven-resolver), it is not designed/intended to
> >
> > > > suddenly have no dependency at hand to work with. The dependency
> node in
> > > > the graph already exists and the only thing that's left to do is
> filling
> > > > it with the right information. I would have to rewrite/change that
> code
> > > > as well. I.e. the code would have to check for a dependencyOverride
> with
> > > > a matching original with no override. To be honest, I personally find
> > > > that to be confusing. An exclusion should be explicit, because it
> > > > carries
> > > > a lot of weight in my opinion. The absence of an XML element should
> not
> > > > make for an exclusion. Global excludes should exist though, just in a
> > > > different way.>
> > > >
> > > >
> > > > @Romain, I disagree that not defining the version in an override
> could
> > > > be
> > > > a source of big issues, because it would have to be defined in
> > > > dependency
> > > > management anyway, so it's basically there. Changing the major
> version
> > > > is
> > > > possible, even today, simply by using dependency management. It is
> the
> > > > responsibility of the developer to provide a proper override (which
> is
> > > > why
> > > > I suggested a different name, dropinReplacement, to make the intent
> > > > clearer). Still, as stated earlier, I will see what I can do. No
> > > > promises
> > > > though. :)
> > >
> > > I never said I like that but it is what it is so "it would have to be
> > > defined in dependency management" is an assumption you cannot do and is
> > > erroneous and I don't see us saying you can't use this override feature
> > > and/or we break your project if you do so I guess we don't have much
> > > choice
> > > than baking it completely and not half.
> > >
> > > Keep in mind dependencyManagement does not behave as dependency
> override
> > > but that it solves similar issues (controlling your dependency graph
> for
> > > submodules since in a single module it is not that useful and excludes
> are
> > > more straight forwards) so as an user you will want to put it in the
> same
> > > (root? ;)) pom to keep the maintenance easy - spreading overrides in
> all
> > > poms is not easy to handle in time, this is why mgt block beats
> dependency
> > > for ex in multimodule projects, I don't see why it wouldn't be the same
> > > for
> > > overrides.
> > >
> > > Alternatively we can fail if we hit this case to prevent overrides in
> such
> > > a case, can be okish in first versions maybe?
> > >
> > > > I agree, having 2 dependencies with the same coordinates but
> different
> > > > versions is a common thing. But in a single Maven module
> maven-resolver
> > > > would see to it that there's only one version on the classpath. After
> > > > all,
> > > > we're not talking about OSGi (thank god). It's different for multiple
> > > > Maven
> >
> > modules though and you know it, so I won't elaborate.
> >
> > > Would mean you forbid overrides in packaging=pom modules, not sure it
> > > would
> > > be that useful to do so since you would duplicate the override in all
> > > modules.
> > > Makes a lot of noise compared to excludes in a depMgt block form my
> quick
> > > tests so guess it is not the intent ;).
> > >
> > > > And yes, overriding the classifier (and extension/type) should be
> > > > possible
> > > > too. And it already is, but it needs more testing, which I'm working
> on.
> > >
> > > 👍
> > >
> > > > Kind regards
> > > > Enno
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > Sent: Monday, November 22, 2021 11:00 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > >
> > > >
> > > > Hi all,
> > > >
> > > >
> > > >
> > > > I fear not defining the version is likely a source of big issues and
> > > > worse
> > > > than not having this feature at all since often, when you change the
> > > > major,
> >
> > you change totally the dependency and the override will just not
> >
> > > > work. You can indeed say you must not have 2 dependencies in
> different
> > > > versions but it is what it is and it is not that uncommon - in
> > > > particular
> > > > for libs (and if you want to force a single version you use
> dependency
> > > > management). So if this feature is desired I fear it must include the
> > > > version and likely manage the classifier as well to work.
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> https://www.packtpub.com/application-development/java-ee-8-high-performa
> > > > nc
> > > > e
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a
> > > > écrit
> > > >
> > > > > Hi Enno,
> > > > >
> > > > >
> > > > >
> > > > > On point 1, figuring out the order of events in a build can be
> > > >
> > > > challenging
> > > >
> > > > > for newbies since Maven is declarative. For example profiles are
> > > > > resolved
> > > > > early on and this is reflected by their place in the pom. Although
> > > > > that's
> > > > > really about config composition, having the overrides under project
> > > > > could
> > > > > also hint at their special nature. No strong argument to make.
> > > > >
> > > > >
> > > > >
> > > > > Point 2, you say you are following a separation of concerns, but it
> > > > > seems
> > > > > rather you are forcing one. By requiring dependency management the
> > > > > result
> > > > > is a tight coupling between stages of resolving the final
> dependencies
> > > >
> > > > (not
> > > >
> > > > > being self-contained, you probably *should* make
> dependencyOverrides a
> > > > > child of dependencyManagement).
> > > > > Maven doesn't require managing dependencies, but your overrides do.
> > > >
> > > > There's
> > > >
> > > > > no harm in picking up config provided by DM, but why force the
> > > > > relationship? If someone wants to add an exclude at the time of an
> > > > > override, frankly that should just be "not your problem". Reusing
> an
> > > > > existing structure is surely preferable to inventing another one?
> > > > > Would
> > > >
> > > > the
> > > >
> > > > > enforcer rules have to learn about your new structure?
> > > > > I see why you went the path of only groupId:artifactId - you copied
> > > > > the
> > > > > exclusion structure. But then excluding doesn't require DM.
> > > > >
> > > > >
> > > > >
> > > > > You're right about wrapping the lists. Will you at least allow not
> > > >
> > > > defining
> > > >
> > > > > a dependency at all, aka a global exclude?
> > > > >
> > > > >
> > > > >
> > > > > Delany
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke
> > > > > <Enno.Thieleke@holisticon.de
> > > > >
> > > > > wrote:
> > > > > > Hi, Delany,
> > > > > >
> > > > > >
> > > > > >
> > > > > > thanks for the feedback.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I get your point that management and overrides can be seen as
> > > > >
> > > > > independent.
> > > > >
> > > > > > To be honest, I'm really not picky about where in the POM
> overrides
> > > > >
> > > > > should
> > > > >
> > > > > > be located. I was hoping for opinions on this from others (and
> was
> > > > > > not
> > > > > > disappointed) and at least one strong opinion from the Maven core
> > > > > > team.
> > > > >
> > > > > As
> > > > >
> > > > > > to why I put overrides in the management section in the first
> place:
> > > > > simply
> > > > >
> > > > > > because I saw overrides as a management subject.
> > > > > >
> > > > > >
> > > > > >
> > > > > > About using the existing dependency tag to define replacements: I
> > > > > > tried
> > > > > > that (in a way, I still used a different tag name though). The
> issue
> > > > > > I
> > > > >
> > > > > have
> > > > >
> > > > > > with it is that the dependency tag can also take version,
> > > > > > exclusions,
> > > > > > optional, etc. and I want that to be in the
> > > > > > /project/dependencyManagement/dependencies section. I'm applying
> the
> > > > > > separation of concerns principle here: overrides should simply
> map
> > > > >
> > > > > artifact
> > > > >
> > > > > > coordinates whereas managed dependencies are all about the right
> > > >
> > > > versions
> > > >
> > > > > > and such. Or maybe the managed dependencies should also provide
> the
> > > > > > override information? The entire existing implementation can
> still
> > > > > > be
> > > > > > changed with little effort.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I also thought about allowing 0..n overrides for one original,
> but I
> > > > > > decided to make it a 1:1 mapping. Let me explain: First, I think
> it
> > > > > > is
> > > > > > currently not possible to have lists in POMs without a wrapping
> > > >
> > > > element.
> > > >
> > > > > > One would have to write:
> > > > > >
> > > > > >
> > > > > >
> > > > > > <!-- Simplified code for brevity -->
> > > > > > <dependencyOverrides>
> > > > > >
> > > > > > <dependencyOverride>
> > > > > >
> > > > > > <original/>
> > > > > > <dependencies>
> > > > > >
> > > > > > <dependency/>
> > > > > > ...
> > > > > >
> > > > > > </dependencies>
> > > > > >
> > > > > > </dependencyOverride>
> > > > > >
> > > > > > </dependencyOverrides>
> > > > > >
> > > > > >
> > > > > >
> > > > > > Please correct me on this if I'm wrong. Second, I think most of
> the
> > > >
> > > > time
> > > >
> > > > > > people will be having 1:1 mappings anyway and with that in mind,
> > > > > > having
> > > > >
> > > > > the
> > > > >
> > > > > > need to use lists which require a wrapping element would bloat a
> > > > > > POM.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Long story short, your first point is up for discussion. If more
> > > > > > people
> > > > > > want overrides located elsewhere, then that's fine by me.
> Regarding
> > > >
> > > > your
> > > >
> > > > > > second point, I think the current approach is good and people
> would
> > > >
> > > > have
> > > >
> > > > > to
> > > > >
> > > > > > provide strong arguments to convince me of a different approach.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Again, thanks for the feedback, it's really appreciated and if
> you
> > > > > > have
> > > > > > more, please let me know.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards,
> > > > > > Enno
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Delany <de...@gmail.com>
> > > > > > Sent: Sunday, November 21, 2021 4:46 AM
> > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Enno,
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2 things. I'd want to emphasise that the resolution of dependency
> > > > > > management info and the dependency overrides (more like a reactor
> > > > > > management concern) are independent of one another. Can achieve
> by
> > > > > > promoting the tag to project.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Then why not use the existing dependency tag to define the
> > > > >
> > > > > replacement(s).
> > > > >
> > > > > > Accept 0, 1 or many.
> > > > > >
> > > > > >
> > > > > >
> > > > > > ...
> > > > > > <groupId>a</groupId>
> > > > > > <artifactId>a</artifactId>
> > > > > > <dependencyOverrides>
> > > > > >
> > > > > > <dependencyOverride>
> > > > > >
> > > > > > <original>
> > > > > >
> > > > > > <groupId>y</groupId>
> > > > > > <artifactId>y</artifactId>
> > > > > >
> > > > > > </original>
> > > > > > <dependency>
> > > > > >
> > > > > > <groupId>z</groupId>
> > > > > > <artifactId>z</artifactId>
> > > > > >
> > > > > > </dependency>
> > > > > > <dependency>
> > > > > >
> > > > > > <groupId>q</groupId>
> > > > > > <artifactId>q</artifactId>
> > > > > >
> > > > > > </dependency>
> > > > > >
> > > > > > </dependencyOverride>
> > > > > >
> > > > > > </dependencyOverrides>
> > > > > > <dependencies>
> > > > > >
> > > > > > <dependency>
> > > > > >
> > > > > > <groupId>w</groupId>
> > > > > > <artifactId>w</artifactId>
> > > > > >
> > > > > > </dependency>
> > > > > > <dependency>
> > > > > >
> > > > > > <groupId>x</groupId>
> > > > > > <artifactId>x</artifactId>
> > > > > >
> > > > > > </dependency>
> > > > > >
> > > > > > </dependencies>
> > > > > > ...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Delany
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> > > >
> > > > Enno.Thieleke@holisticon.de
> > > >
> > > > > > wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > it's been a while and I've made some progress regarding
> > > > > > > overrides/replacements and wanted to share the current state.
> > > > > > >
> > > > > > > What's implemented/changed:
> > > > > > > * The POM version has been upgraded to 4.1.0 and will
> accept
> > > > > > >
> > > > > > > /project/dependencyManagement/dependencyOverrides which in turn
> > > > > > > can
> > > > >
> > > > > take
> > > > >
> > > > > > > the coordinates of original and overriding artifacts.
> > > > > > >
> > > > > > > * Overrides can be declared on any POM level in a hierarchy
> > > > > > > POMs
> > > > > >
> > > > > > (i.e.
> > > > > >
> > > > > > > parents and children.
> > > > > > >
> > > > > > > * Overrides can be imported from other POMs using the
> existing
> > > > > > >
> > > > > > > `import` scope for POMs in the dependencyManagement section.
> > > > > > >
> > > > > > > * If the same original artifact is overridden on different
> > > >
> > > > levels,
> > > >
> > > > > > the
> > > > > >
> > > > > > > "most downstream" wins.
> > > > > > >
> > > > > > > * An override *must* be accompanied by an entry in the
> > > > > > >
> > > > > > > dependencyManagement section. Maven generates an error and
> halts,
> > > > > > > if
> > > > > >
> > > > > > that's
> > > > > >
> > > > > > > not the case.
> > > > > > >
> > > > > > > * If an override is declared and consumed in the same
> > > > > > > effective
> > > > >
> > > > > POM,
> > > > >
> > > > > > > Maven generates a warning that the user should use the
> overriding
> > > > > >
> > > > > > artifact
> > > > > >
> > > > > > > instead of the original artifact.
> > > > > > >
> > > > > > > * The dependencies of an effective POM remain untouched.
> > > >
> > > > Overrides
> > > >
> > > > > > are
> > > > > >
> > > > > > > declared in POMs, but the act of overriding is implemented in
> > > > > > > maven-resolver.
> > > > > > >
> > > > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT,
> > > > > > > because
> > > > > > >
> > > > > > > interfaces needed additions. While some might consider this to
> be
> > > > > > > a
> > > > >
> > > > > minor
> > > > >
> > > > > > > change, I consider this to be a major change, because the
> > > > > > > interfaces
> > > > >
> > > > > are
> > > > >
> > > > > > > not (and cannot be, yet) sealed.
> > > > > > >
> > > > > > > * It is possible to override overrides of transitive
> > > >
> > > > dependencies.
> > > >
> > > > > In
> > > > >
> > > > > > > other words, it is possible to override overrides of POMs of
> > > > > >
> > > > > > dependencies.
> > > > > >
> > > > > > > While working on this I thought about names for
> > > >
> > > > overrides/replacements.
> > > >
> > > > > > > I'm still open to suggestions and pretty much undecided.
> Another
> > > > > > > name
> > > > > >
> > > > > > that
> > > > > >
> > > > > > > popped into my head is `dropinReplacements`, because it makes
> the
> > > > >
> > > > > intent
> > > > >
> > > > > > > very clear.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > For those of you who are interested, here are the links to the
> > > > > > > code
> > > > >
> > > > > again
> > > > >
> > > > > > > (so it's just one click away):
> > > > > > > *
> > > > > >
> > > > > >
> https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > > >
> > > > > > > *
> https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > > > > *
> > > > > > >
> https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > > > > >
> > > > > > > Also, I've rebased my changes onto master very recently.
> > > >
> > > > > > > And here's the proposal itself:
> > > >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > > er
> > > > rides.md
> > > >
> > > > > > > If you find the time to look, please let me know what you think
> > > > > > > and
> > > > >
> > > > > what
> > > > >
> > > > > > > you think is missing.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > > >
> > > > > > > A few notes on the proposal:
> > > > > > > - Leave a dependency graph virtually untouched.
> > > > > > > Only change/override nodes in place. Don't exclude
> dependencies
> > > >
> > > > and
> > > >
> > > > > > > include new ones on a different level in the graph.
> > > > > > >
> > > > > > > Think, whatever it means, served dependencies in mojo shouldnt
> > > > > > > have
> > > >
> > > > to
> > > >
> > > > > > rely
> > > > > >
> > > > > > > on this new section using getXArtifact or dependency visitor.
> No
> > > > > > > real
> > > > > >
> > > > > > good
> > > > > >
> > > > > > > reason to break everyone there.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > A not used override must break the build (it is an unexpected
> bug
> > > > > > > and
> > > > > >
> > > > > > would
> > > > > >
> > > > > > > make the dev life hard otherwise). I perfectly see that it will
> > > > > > > break
> > > > > > > building a submodule in several cases but otherwise the section
> > > > > > > will
> > > > > >
> > > > > > become
> > > > > >
> > > > > > > unmanageable with time (see hibernate or cxf example) and since
> > > > > > > you
> > > > >
> > > > > loose
> > > > >
> > > > > > > the dependency relationship with this option compared to
> > > > > > > exclusions,
> > > >
> > > > it
> > > >
> > > > > > way
> > > > > >
> > > > > > > too much work to maintain it in practise. (This is why I think
> it
> > > > > >
> > > > > > shouldnt
> > > > > >
> > > > > > > be done this way but very worse case at dependency level giving
> > > > > > > hints
> > > > >
> > > > > for
> > > > >
> > > > > > > overrides and not elsewhere, mixed with dependency
> managementnit
> > > > > > > is
> > > > > >
> > > > > > trivial
> > > > > >
> > > > > > > to handle and maintain then).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Pom rewriter must handle this section by dropping it and
> replacing
> > > > > > > it
> > > > >
> > > > > by
> > > > >
> > > > > > > exludes to keep compatibility with 3rd party resolvers
> > > > > > > (deployment).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Overall, I still think it would be neat to see it as an
> extension
> > > > > > > for
> > > > > >
> > > > > > maven
> > > > > >
> > > > > > > 3.8.2 or 4 to be testable and validate design choices and
> actual
> > > >
> > > > usage
> > > >
> > > > > on
> > > > >
> > > > > > > real dependencies compared to current option.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > > > >
> > > > > Enno.Thieleke@holisticon.de
> > > > >
> > > > > > > a
> > > > > > >
> > > > > > > écrit :
> > > > > > > > Hello again,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I tried to create a proposal in/under
> > > >
> > > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > >
> > > > > > > ,
> > > > > > >
> > > > > > > > but I'm not allowed to, which makes sense since I'm new to
> the
> > > >
> > > > wiki,
> > > >
> > > > > > so I
> > > > > >
> > > > > > > > committed a proposal to my fork:
> > > >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > > er
> > > > rides.md
> > > >
> > > > > > > > The current version probably still contains errors and misses
> > > >
> > > > details
> > > >
> > > > > > but
> > > > > >
> > > > > > > > I imo they need to be worked out in a group effort.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Some feedback/comments would be appreciated.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Maybe you could create a proposal page in your wiki and
> grant me
> > > >
> > > > edit
> > > >
> > > > > > > > rights (user eth)?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Kind regards
> > > > > > > > Enno
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Michael,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Just a few more questions before I start.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > For the issue: Would reopening
> > > > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or
> would
> > > >
> > > > you
> > > >
> > > > > > like
> > > > > >
> > > > > > > > to see a new one?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Where do I create the proposal?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > What should be created first, the issue or the proposal? I'm
> > > >
> > > > asking,
> > > >
> > > > > > > > because in the proposal we'd work out the details and after
> > > > > > > > that's
> > > > > >
> > > > > > done,
> > > > > >
> > > > > > > > that's where the issue becomes relevant (no issue, no code
> > > >
> > > > changes).
> > > >
> > > > > At
> > > > >
> > > > > > > > least that's how I'm used to implementing changes like this.
> I
> > > >
> > > > don't
> > > >
> > > > > > want
> > > > > >
> > > > > > > > to have created unnecessary noise in your issue system, if -
> for
> > > >
> > > > some
> > > >
> > > > > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Is it ok to use one issue for changes in both projects, Maven
> > > > > > > > and
> > > > > > > > maven-resolver?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Kind regards
> > > > > > > > Enno
> > > > > > > > ________________________________
> > > > > > > > From: Michael Osipov <mi...@apache.org>
> > > > > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
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 <En...@holisticon.de>
Sent: Sunday, December 26, 2021 8:47 PM
To: Maven Developers List <de...@maven.apache.org>
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 git@github.com:strohmattenverleger/maven-MNG-4530-example.git
Just build git@github.com:strohmattenverleger/maven-resolver.git and git@github.com:strohmattenverleger/maven.git first.
3. After reading your article I can now understand why it would/could be a bad idea to simply update the POM version from 4.0 to, say, 4.1. A Maven 3 installation would be obsolete if there was a single POM in a graph that's "too new". Let's imagine updating the POM of Guava or SLF4J to something like 4.1 for a second. Boom.
To be honest: I wouldn't mind being forced to update to a newer Maven version in such a case. The world keeps turning after all. :) But if it can be avoided with good measures, then that approach should be preferred. And I think the build vs. consumer POM approach is promising (no plugin configurations and such in consumer POMs), which brings me to your next point.
4. I'm having trouble imagining a way to generate a consumer POM (4.0) from my build POM (i.e. a POM with overrides). Yes, one could juggle with excludes (again), but the idea of dependency overrides is to modify certain nodes in a dependency graph without the need for exclusions. This is why I went for a minor update of the POM schema in the first place. I would like overrides to be transparent and concise.
Unfortunately I can't think of a way how to implement this feature for older Maven versions without "them knowing what they are dealing with", if we are talking about proper overrides/replacements, not just exclusions and additional dependencies. Not very satisfying, I know. Do you have an idea? I'm open to suggestions.
Regarding MNG-6772: Interesting. I never experienced this issue myself, but I agree with your expectation in https://issues.apache.org/jira/browse/MNG-6772?focusedCommentId=17310052&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310052
Since there's no corresponding branch in https://github.com/apache/maven do you need someone to give a solution to this issue another try before we get our hands dirty with other stuff? Did I unterstand you correctly?
Regards,
Enno
________________________________
From: Hervé BOUTEMY <he...@free.fr>
Sent: Wednesday, December 22, 2021 8:42 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Fw: Request for Enhancement: Dependency Overrides
I forgot: last but not least
we have consistency issues with parent POM and dependencyManagement POM import downloads when repositories are defined in projects pom.xml
see https://issues.apache.org/jira/browse/MNG-6772 and linked issues
while working on all this dependencies management, it would be useful to fix this issue that is blocking other improvements:
- definition of central in settings.xml https://issues.apache.org/jira/browse/MNG-4645
- pluginManagement import https://issues.apache.org/jira/browse/MNG-5588 = I don't want to copy/paste a 2nd time the buggy code from dependencyManagement import as it was copied from parent resolution...
Regards,
Hervé
Le mercredi 22 décembre 2021, 08:37:08 CET Hervé BOUTEMY a écrit :
> my own quick opinion:
>
> 1. I did not review the full email thread, so is
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overr
> ides.md still the current state of the idea?
>
> 2. can you add concrete examples, please?
>
> 3. given the impact, I fear this may be for Maven 5: we clearly need to
> focus on releasing Maven 4 first
> https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
>
> 4. as part of the build vs consumer pom approach, do you think a consumer
> pom can be generated from your build pom?
>
> Regards,
>
> Hervé
>
> Le lundi 20 décembre 2021, 21:25:39 CET Enno Thieleke a écrit :
> > Hello again,
> >
> > judging by the increased traffic in this mailing list some of you seem to
> > be on vacation. That's nice. I was hoping that this might be a good time
> > to ask for your opinion again about what I wrote a couple of weeks ago?
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Enno Thieleke <En...@holisticon.de>
> > Sent: Friday, December 3, 2021 10:54 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi,
> >
> > concerning the request to change the override XML element to a
> > fully-fledged dependency, thus removing the need for accompanying managed
> > dependencies...
> >
> > tl;dr
> > I would add a version attribute, nothing more, to the override XML
> > element.
> > The rest would remain unchanged.
> >
> > Full version:
> >
> > If I turned the override XML element into a fully-fledged dependency,
> > should we support properties such as `scope` and `optional`? In my
> > opinion we shouldn't, because that's still subject to original dependency
> > definitions, not overrides. If people want to change the scope or add
> > exclusions, they should stick to dependency management. That's what it's
> > there for.
> I think
>
> > it's enough to just add a version child-element to the current override
> > XML
> > element. That would remove the need for accompanying managed dependencies
> > for just versions and in many simple cases that'd suffice, wouldn't you
> > agree? I think we should draw the line here between changing artifact
> > coordinates, a special kind of dependency management, and managing other
> > dependency properties -> separation of concerns. Suppose I added a version
> > child-element, I'd still have concerns about moving dependencyOverrides up
> > one level so that it would be a sibling of dependencyManagement. Imagine I
> > moved dependencyOverrides up one level. How would we import them properly?
> > Currently importing a POM imports both: managed dependencies as well as
> > overrides and I think that wouldn't be the right approach anymore. Would
> > special import XML elements do the trick? Such as this:
> > <dependencyManagement>
> >
> > <dependencies>
> >
> > <dependency>
> >
> > ...
> > <scope>import</scope> <!-- Imports managed dependencies -->
> >
> > </dependency>
> >
> > </dependencies>
> >
> > </dependencyManagement>
> > <dependencyOverrides>
> >
> > <imports>
> >
> > <import> <!-- Imports overrides; the packaging of the import MUST be
> > pom
> >
> > -->
>
> <groupId/>
>
> > <artifactId/>
> > <version/>
> >
> > </import>
> >
> > </imports>
> > ...
> >
> > </dependencyOverrides>
> >
> > To be honest: I think that'd suck. Another way would be to introduce a new
> > special purpose scope, but I think the existing special purpose scope
> > "import" is perfect: it's meant to import dependency management
> > information
> > from different POMs and since overrides affect dependencies in the sense
> > that they manage dependency coordinates, we're still talking about
> > dependency management.
> >
> > Please let me know what you think.
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Monday, November 22, 2021 2:33 PM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de>
> > a
> >
> > écrit :
> > > Hello,
> > >
> > >
> > >
> > > @Delany, regarding 1 and 2: If I added all the other elements of the
> > > dependency tag, I would have to apply dependency management anyway if
> > > present (and I played around with it for a bit), but I see your point.
> > > Maybe using the dependency tag (I'd still name it override though) is
> > > "good
>
> enough" for small projects/POMs. I will throw a bit of time at it
>
> > > and check for "bad" implications.
> > >
> > >
> > >
> > > Making the override tag optional to have some sort of global exclusion
> > > mechanism is out of scope. Let me explain: When dependency management
> > > comes
>
> into play (in maven-resolver), it is not designed/intended to
>
> > > suddenly have no dependency at hand to work with. The dependency node in
> > > the graph already exists and the only thing that's left to do is filling
> > > it with the right information. I would have to rewrite/change that code
> > > as well. I.e. the code would have to check for a dependencyOverride with
> > > a matching original with no override. To be honest, I personally find
> > > that to be confusing. An exclusion should be explicit, because it
> > > carries
> > > a lot of weight in my opinion. The absence of an XML element should not
> > > make for an exclusion. Global excludes should exist though, just in a
> > > different way.>
> > >
> > >
> > > @Romain, I disagree that not defining the version in an override could
> > > be
> > > a source of big issues, because it would have to be defined in
> > > dependency
> > > management anyway, so it's basically there. Changing the major version
> > > is
> > > possible, even today, simply by using dependency management. It is the
> > > responsibility of the developer to provide a proper override (which is
> > > why
> > > I suggested a different name, dropinReplacement, to make the intent
> > > clearer). Still, as stated earlier, I will see what I can do. No
> > > promises
> > > though. :)
> >
> > I never said I like that but it is what it is so "it would have to be
> > defined in dependency management" is an assumption you cannot do and is
> > erroneous and I don't see us saying you can't use this override feature
> > and/or we break your project if you do so I guess we don't have much
> > choice
> > than baking it completely and not half.
> >
> > Keep in mind dependencyManagement does not behave as dependency override
> > but that it solves similar issues (controlling your dependency graph for
> > submodules since in a single module it is not that useful and excludes are
> > more straight forwards) so as an user you will want to put it in the same
> > (root? ;)) pom to keep the maintenance easy - spreading overrides in all
> > poms is not easy to handle in time, this is why mgt block beats dependency
> > for ex in multimodule projects, I don't see why it wouldn't be the same
> > for
> > overrides.
> >
> > Alternatively we can fail if we hit this case to prevent overrides in such
> > a case, can be okish in first versions maybe?
> >
> > > I agree, having 2 dependencies with the same coordinates but different
> > > versions is a common thing. But in a single Maven module maven-resolver
> > > would see to it that there's only one version on the classpath. After
> > > all,
> > > we're not talking about OSGi (thank god). It's different for multiple
> > > Maven
>
> modules though and you know it, so I won't elaborate.
>
> > Would mean you forbid overrides in packaging=pom modules, not sure it
> > would
> > be that useful to do so since you would duplicate the override in all
> > modules.
> > Makes a lot of noise compared to excludes in a depMgt block form my quick
> > tests so guess it is not the intent ;).
> >
> > > And yes, overriding the classifier (and extension/type) should be
> > > possible
> > > too. And it already is, but it needs more testing, which I'm working on.
> >
> > 👍
> >
> > > Kind regards
> > > Enno
> > >
> > >
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Monday, November 22, 2021 11:00 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > >
> > > I fear not defining the version is likely a source of big issues and
> > > worse
> > > than not having this feature at all since often, when you change the
> > > major,
>
> you change totally the dependency and the override will just not
>
> > > work. You can indeed say you must not have 2 dependencies in different
> > > versions but it is what it is and it is not that uncommon - in
> > > particular
> > > for libs (and if you want to force a single version you use dependency
> > > management). So if this feature is desired I fear it must include the
> > > version and likely manage the classifier as well to work.
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > > https://www.packtpub.com/application-development/java-ee-8-high-performa
> > > nc
> > > e
> > >
> > >
> > >
> > >
> > >
> > >
> > > Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a
> > > écrit
> > >
> > > > Hi Enno,
> > > >
> > > >
> > > >
> > > > On point 1, figuring out the order of events in a build can be
> > >
> > > challenging
> > >
> > > > for newbies since Maven is declarative. For example profiles are
> > > > resolved
> > > > early on and this is reflected by their place in the pom. Although
> > > > that's
> > > > really about config composition, having the overrides under project
> > > > could
> > > > also hint at their special nature. No strong argument to make.
> > > >
> > > >
> > > >
> > > > Point 2, you say you are following a separation of concerns, but it
> > > > seems
> > > > rather you are forcing one. By requiring dependency management the
> > > > result
> > > > is a tight coupling between stages of resolving the final dependencies
> > >
> > > (not
> > >
> > > > being self-contained, you probably *should* make dependencyOverrides a
> > > > child of dependencyManagement).
> > > > Maven doesn't require managing dependencies, but your overrides do.
> > >
> > > There's
> > >
> > > > no harm in picking up config provided by DM, but why force the
> > > > relationship? If someone wants to add an exclude at the time of an
> > > > override, frankly that should just be "not your problem". Reusing an
> > > > existing structure is surely preferable to inventing another one?
> > > > Would
> > >
> > > the
> > >
> > > > enforcer rules have to learn about your new structure?
> > > > I see why you went the path of only groupId:artifactId - you copied
> > > > the
> > > > exclusion structure. But then excluding doesn't require DM.
> > > >
> > > >
> > > >
> > > > You're right about wrapping the lists. Will you at least allow not
> > >
> > > defining
> > >
> > > > a dependency at all, aka a global exclude?
> > > >
> > > >
> > > >
> > > > Delany
> > > >
> > > >
> > > >
> > > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke
> > > > <Enno.Thieleke@holisticon.de
> > > >
> > > > wrote:
> > > > > Hi, Delany,
> > > > >
> > > > >
> > > > >
> > > > > thanks for the feedback.
> > > > >
> > > > >
> > > > >
> > > > > I get your point that management and overrides can be seen as
> > > >
> > > > independent.
> > > >
> > > > > To be honest, I'm really not picky about where in the POM overrides
> > > >
> > > > should
> > > >
> > > > > be located. I was hoping for opinions on this from others (and was
> > > > > not
> > > > > disappointed) and at least one strong opinion from the Maven core
> > > > > team.
> > > >
> > > > As
> > > >
> > > > > to why I put overrides in the management section in the first place:
> > > > simply
> > > >
> > > > > because I saw overrides as a management subject.
> > > > >
> > > > >
> > > > >
> > > > > About using the existing dependency tag to define replacements: I
> > > > > tried
> > > > > that (in a way, I still used a different tag name though). The issue
> > > > > I
> > > >
> > > > have
> > > >
> > > > > with it is that the dependency tag can also take version,
> > > > > exclusions,
> > > > > optional, etc. and I want that to be in the
> > > > > /project/dependencyManagement/dependencies section. I'm applying the
> > > > > separation of concerns principle here: overrides should simply map
> > > >
> > > > artifact
> > > >
> > > > > coordinates whereas managed dependencies are all about the right
> > >
> > > versions
> > >
> > > > > and such. Or maybe the managed dependencies should also provide the
> > > > > override information? The entire existing implementation can still
> > > > > be
> > > > > changed with little effort.
> > > > >
> > > > >
> > > > >
> > > > > I also thought about allowing 0..n overrides for one original, but I
> > > > > decided to make it a 1:1 mapping. Let me explain: First, I think it
> > > > > is
> > > > > currently not possible to have lists in POMs without a wrapping
> > >
> > > element.
> > >
> > > > > One would have to write:
> > > > >
> > > > >
> > > > >
> > > > > <!-- Simplified code for brevity -->
> > > > > <dependencyOverrides>
> > > > >
> > > > > <dependencyOverride>
> > > > >
> > > > > <original/>
> > > > > <dependencies>
> > > > >
> > > > > <dependency/>
> > > > > ...
> > > > >
> > > > > </dependencies>
> > > > >
> > > > > </dependencyOverride>
> > > > >
> > > > > </dependencyOverrides>
> > > > >
> > > > >
> > > > >
> > > > > Please correct me on this if I'm wrong. Second, I think most of the
> > >
> > > time
> > >
> > > > > people will be having 1:1 mappings anyway and with that in mind,
> > > > > having
> > > >
> > > > the
> > > >
> > > > > need to use lists which require a wrapping element would bloat a
> > > > > POM.
> > > > >
> > > > >
> > > > >
> > > > > Long story short, your first point is up for discussion. If more
> > > > > people
> > > > > want overrides located elsewhere, then that's fine by me. Regarding
> > >
> > > your
> > >
> > > > > second point, I think the current approach is good and people would
> > >
> > > have
> > >
> > > > to
> > > >
> > > > > provide strong arguments to convince me of a different approach.
> > > > >
> > > > >
> > > > >
> > > > > Again, thanks for the feedback, it's really appreciated and if you
> > > > > have
> > > > > more, please let me know.
> > > > >
> > > > >
> > > > >
> > > > > Kind regards,
> > > > > Enno
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Delany <de...@gmail.com>
> > > > > Sent: Sunday, November 21, 2021 4:46 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > >
> > > > >
> > > > > Hi Enno,
> > > > >
> > > > >
> > > > >
> > > > > 2 things. I'd want to emphasise that the resolution of dependency
> > > > > management info and the dependency overrides (more like a reactor
> > > > > management concern) are independent of one another. Can achieve by
> > > > > promoting the tag to project.
> > > > >
> > > > >
> > > > >
> > > > > Then why not use the existing dependency tag to define the
> > > >
> > > > replacement(s).
> > > >
> > > > > Accept 0, 1 or many.
> > > > >
> > > > >
> > > > >
> > > > > ...
> > > > > <groupId>a</groupId>
> > > > > <artifactId>a</artifactId>
> > > > > <dependencyOverrides>
> > > > >
> > > > > <dependencyOverride>
> > > > >
> > > > > <original>
> > > > >
> > > > > <groupId>y</groupId>
> > > > > <artifactId>y</artifactId>
> > > > >
> > > > > </original>
> > > > > <dependency>
> > > > >
> > > > > <groupId>z</groupId>
> > > > > <artifactId>z</artifactId>
> > > > >
> > > > > </dependency>
> > > > > <dependency>
> > > > >
> > > > > <groupId>q</groupId>
> > > > > <artifactId>q</artifactId>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > </dependencyOverride>
> > > > >
> > > > > </dependencyOverrides>
> > > > > <dependencies>
> > > > >
> > > > > <dependency>
> > > > >
> > > > > <groupId>w</groupId>
> > > > > <artifactId>w</artifactId>
> > > > >
> > > > > </dependency>
> > > > > <dependency>
> > > > >
> > > > > <groupId>x</groupId>
> > > > > <artifactId>x</artifactId>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > </dependencies>
> > > > > ...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Delany
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> > >
> > > Enno.Thieleke@holisticon.de
> > >
> > > > > wrote:
> > > > > > Hello,
> > > > > >
> > > > > >
> > > > > >
> > > > > > it's been a while and I've made some progress regarding
> > > > > > overrides/replacements and wanted to share the current state.
> > > > > >
> > > > > > What's implemented/changed:
> > > > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > > >
> > > > > > /project/dependencyManagement/dependencyOverrides which in turn
> > > > > > can
> > > >
> > > > take
> > > >
> > > > > > the coordinates of original and overriding artifacts.
> > > > > >
> > > > > > * Overrides can be declared on any POM level in a hierarchy
> > > > > > POMs
> > > > >
> > > > > (i.e.
> > > > >
> > > > > > parents and children.
> > > > > >
> > > > > > * Overrides can be imported from other POMs using the existing
> > > > > >
> > > > > > `import` scope for POMs in the dependencyManagement section.
> > > > > >
> > > > > > * If the same original artifact is overridden on different
> > >
> > > levels,
> > >
> > > > > the
> > > > >
> > > > > > "most downstream" wins.
> > > > > >
> > > > > > * An override *must* be accompanied by an entry in the
> > > > > >
> > > > > > dependencyManagement section. Maven generates an error and halts,
> > > > > > if
> > > > >
> > > > > that's
> > > > >
> > > > > > not the case.
> > > > > >
> > > > > > * If an override is declared and consumed in the same
> > > > > > effective
> > > >
> > > > POM,
> > > >
> > > > > > Maven generates a warning that the user should use the overriding
> > > > >
> > > > > artifact
> > > > >
> > > > > > instead of the original artifact.
> > > > > >
> > > > > > * The dependencies of an effective POM remain untouched.
> > >
> > > Overrides
> > >
> > > > > are
> > > > >
> > > > > > declared in POMs, but the act of overriding is implemented in
> > > > > > maven-resolver.
> > > > > >
> > > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT,
> > > > > > because
> > > > > >
> > > > > > interfaces needed additions. While some might consider this to be
> > > > > > a
> > > >
> > > > minor
> > > >
> > > > > > change, I consider this to be a major change, because the
> > > > > > interfaces
> > > >
> > > > are
> > > >
> > > > > > not (and cannot be, yet) sealed.
> > > > > >
> > > > > > * It is possible to override overrides of transitive
> > >
> > > dependencies.
> > >
> > > > In
> > > >
> > > > > > other words, it is possible to override overrides of POMs of
> > > > >
> > > > > dependencies.
> > > > >
> > > > > > While working on this I thought about names for
> > >
> > > overrides/replacements.
> > >
> > > > > > I'm still open to suggestions and pretty much undecided. Another
> > > > > > name
> > > > >
> > > > > that
> > > > >
> > > > > > popped into my head is `dropinReplacements`, because it makes the
> > > >
> > > > intent
> > > >
> > > > > > very clear.
> > > > > >
> > > > > >
> > > > > >
> > > > > > For those of you who are interested, here are the links to the
> > > > > > code
> > > >
> > > > again
> > > >
> > > > > > (so it's just one click away):
> > > > > > *
> > > > >
> > > > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > >
> > > > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > > > *
> > > > > > https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > > > >
> > > > > > Also, I've rebased my changes onto master very recently.
> > >
> > > > > > And here's the proposal itself:
> > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > er
> > > rides.md
> > >
> > > > > > If you find the time to look, please let me know what you think
> > > > > > and
> > > >
> > > > what
> > > >
> > > > > > you think is missing.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > >
> > > > > > A few notes on the proposal:
> > > > > > - Leave a dependency graph virtually untouched.
> > > > > > Only change/override nodes in place. Don't exclude dependencies
> > >
> > > and
> > >
> > > > > > include new ones on a different level in the graph.
> > > > > >
> > > > > > Think, whatever it means, served dependencies in mojo shouldnt
> > > > > > have
> > >
> > > to
> > >
> > > > > rely
> > > > >
> > > > > > on this new section using getXArtifact or dependency visitor. No
> > > > > > real
> > > > >
> > > > > good
> > > > >
> > > > > > reason to break everyone there.
> > > > > >
> > > > > >
> > > > > >
> > > > > > A not used override must break the build (it is an unexpected bug
> > > > > > and
> > > > >
> > > > > would
> > > > >
> > > > > > make the dev life hard otherwise). I perfectly see that it will
> > > > > > break
> > > > > > building a submodule in several cases but otherwise the section
> > > > > > will
> > > > >
> > > > > become
> > > > >
> > > > > > unmanageable with time (see hibernate or cxf example) and since
> > > > > > you
> > > >
> > > > loose
> > > >
> > > > > > the dependency relationship with this option compared to
> > > > > > exclusions,
> > >
> > > it
> > >
> > > > > way
> > > > >
> > > > > > too much work to maintain it in practise. (This is why I think it
> > > > >
> > > > > shouldnt
> > > > >
> > > > > > be done this way but very worse case at dependency level giving
> > > > > > hints
> > > >
> > > > for
> > > >
> > > > > > overrides and not elsewhere, mixed with dependency managementnit
> > > > > > is
> > > > >
> > > > > trivial
> > > > >
> > > > > > to handle and maintain then).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pom rewriter must handle this section by dropping it and replacing
> > > > > > it
> > > >
> > > > by
> > > >
> > > > > > exludes to keep compatibility with 3rd party resolvers
> > > > > > (deployment).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Overall, I still think it would be neat to see it as an extension
> > > > > > for
> > > > >
> > > > > maven
> > > > >
> > > > > > 3.8.2 or 4 to be testable and validate design choices and actual
> > >
> > > usage
> > >
> > > > on
> > > >
> > > > > > real dependencies compared to current option.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > > >
> > > > Enno.Thieleke@holisticon.de
> > > >
> > > > > > a
> > > > > >
> > > > > > écrit :
> > > > > > > Hello again,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I tried to create a proposal in/under
> > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > >
> > > > > > ,
> > > > > >
> > > > > > > but I'm not allowed to, which makes sense since I'm new to the
> > >
> > > wiki,
> > >
> > > > > so I
> > > > >
> > > > > > > committed a proposal to my fork:
> > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > er
> > > rides.md
> > >
> > > > > > > The current version probably still contains errors and misses
> > >
> > > details
> > >
> > > > > but
> > > > >
> > > > > > > I imo they need to be worked out in a group effort.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Some feedback/comments would be appreciated.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Maybe you could create a proposal page in your wiki and grant me
> > >
> > > edit
> > >
> > > > > > > rights (user eth)?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Michael,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Just a few more questions before I start.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > For the issue: Would reopening
> > > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> > >
> > > you
> > >
> > > > > like
> > > > >
> > > > > > > to see a new one?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Where do I create the proposal?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > What should be created first, the issue or the proposal? I'm
> > >
> > > asking,
> > >
> > > > > > > because in the proposal we'd work out the details and after
> > > > > > > that's
> > > > >
> > > > > done,
> > > > >
> > > > > > > that's where the issue becomes relevant (no issue, no code
> > >
> > > changes).
> > >
> > > > At
> > > >
> > > > > > > least that's how I'm used to implementing changes like this. I
> > >
> > > don't
> > >
> > > > > want
> > > > >
> > > > > > > to have created unnecessary noise in your issue system, if - for
> > >
> > > some
> > >
> > > > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Is it ok to use one issue for changes in both projects, Maven
> > > > > > > and
> > > > > > > maven-resolver?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > > ________________________________
> > > > > > > From: Michael Osipov <mi...@apache.org>
> > > > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
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 git@github.com:strohmattenverleger/maven-MNG-4530-example.git
Just build git@github.com:strohmattenverleger/maven-resolver.git and git@github.com:strohmattenverleger/maven.git first.
3. After reading your article I can now understand why it would/could be a bad idea to simply update the POM version from 4.0 to, say, 4.1. A Maven 3 installation would be obsolete if there was a single POM in a graph that's "too new". Let's imagine updating the POM of Guava or SLF4J to something like 4.1 for a second. Boom.
To be honest: I wouldn't mind being forced to update to a newer Maven version in such a case. The world keeps turning after all. :) But if it can be avoided with good measures, then that approach should be preferred. And I think the build vs. consumer POM approach is promising (no plugin configurations and such in consumer POMs), which brings me to your next point.
4. I'm having trouble imagining a way to generate a consumer POM (4.0) from my build POM (i.e. a POM with overrides). Yes, one could juggle with excludes (again), but the idea of dependency overrides is to modify certain nodes in a dependency graph without the need for exclusions. This is why I went for a minor update of the POM schema in the first place. I would like overrides to be transparent and concise.
Unfortunately I can't think of a way how to implement this feature for older Maven versions without "them knowing what they are dealing with", if we are talking about proper overrides/replacements, not just exclusions and additional dependencies. Not very satisfying, I know. Do you have an idea? I'm open to suggestions.
Regarding MNG-6772: Interesting. I never experienced this issue myself, but I agree with your expectation in https://issues.apache.org/jira/browse/MNG-6772?focusedCommentId=17310052&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310052
Since there's no corresponding branch in https://github.com/apache/maven do you need someone to give a solution to this issue another try before we get our hands dirty with other stuff? Did I unterstand you correctly?
Regards,
Enno
________________________________
From: Hervé BOUTEMY <he...@free.fr>
Sent: Wednesday, December 22, 2021 8:42 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Fw: Request for Enhancement: Dependency Overrides
I forgot: last but not least
we have consistency issues with parent POM and dependencyManagement POM import downloads when repositories are defined in projects pom.xml
see https://issues.apache.org/jira/browse/MNG-6772 and linked issues
while working on all this dependencies management, it would be useful to fix this issue that is blocking other improvements:
- definition of central in settings.xml https://issues.apache.org/jira/browse/MNG-4645
- pluginManagement import https://issues.apache.org/jira/browse/MNG-5588 = I don't want to copy/paste a 2nd time the buggy code from dependencyManagement import as it was copied from parent resolution...
Regards,
Hervé
Le mercredi 22 décembre 2021, 08:37:08 CET Hervé BOUTEMY a écrit :
> my own quick opinion:
>
> 1. I did not review the full email thread, so is
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overr
> ides.md still the current state of the idea?
>
> 2. can you add concrete examples, please?
>
> 3. given the impact, I fear this may be for Maven 5: we clearly need to
> focus on releasing Maven 4 first
> https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
>
> 4. as part of the build vs consumer pom approach, do you think a consumer
> pom can be generated from your build pom?
>
> Regards,
>
> Hervé
>
> Le lundi 20 décembre 2021, 21:25:39 CET Enno Thieleke a écrit :
> > Hello again,
> >
> > judging by the increased traffic in this mailing list some of you seem to
> > be on vacation. That's nice. I was hoping that this might be a good time
> > to ask for your opinion again about what I wrote a couple of weeks ago?
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Enno Thieleke <En...@holisticon.de>
> > Sent: Friday, December 3, 2021 10:54 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi,
> >
> > concerning the request to change the override XML element to a
> > fully-fledged dependency, thus removing the need for accompanying managed
> > dependencies...
> >
> > tl;dr
> > I would add a version attribute, nothing more, to the override XML
> > element.
> > The rest would remain unchanged.
> >
> > Full version:
> >
> > If I turned the override XML element into a fully-fledged dependency,
> > should we support properties such as `scope` and `optional`? In my
> > opinion we shouldn't, because that's still subject to original dependency
> > definitions, not overrides. If people want to change the scope or add
> > exclusions, they should stick to dependency management. That's what it's
> > there for.
> I think
>
> > it's enough to just add a version child-element to the current override
> > XML
> > element. That would remove the need for accompanying managed dependencies
> > for just versions and in many simple cases that'd suffice, wouldn't you
> > agree? I think we should draw the line here between changing artifact
> > coordinates, a special kind of dependency management, and managing other
> > dependency properties -> separation of concerns. Suppose I added a version
> > child-element, I'd still have concerns about moving dependencyOverrides up
> > one level so that it would be a sibling of dependencyManagement. Imagine I
> > moved dependencyOverrides up one level. How would we import them properly?
> > Currently importing a POM imports both: managed dependencies as well as
> > overrides and I think that wouldn't be the right approach anymore. Would
> > special import XML elements do the trick? Such as this:
> > <dependencyManagement>
> >
> > <dependencies>
> >
> > <dependency>
> >
> > ...
> > <scope>import</scope> <!-- Imports managed dependencies -->
> >
> > </dependency>
> >
> > </dependencies>
> >
> > </dependencyManagement>
> > <dependencyOverrides>
> >
> > <imports>
> >
> > <import> <!-- Imports overrides; the packaging of the import MUST be
> > pom
> >
> > -->
>
> <groupId/>
>
> > <artifactId/>
> > <version/>
> >
> > </import>
> >
> > </imports>
> > ...
> >
> > </dependencyOverrides>
> >
> > To be honest: I think that'd suck. Another way would be to introduce a new
> > special purpose scope, but I think the existing special purpose scope
> > "import" is perfect: it's meant to import dependency management
> > information
> > from different POMs and since overrides affect dependencies in the sense
> > that they manage dependency coordinates, we're still talking about
> > dependency management.
> >
> > Please let me know what you think.
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Monday, November 22, 2021 2:33 PM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de>
> > a
> >
> > écrit :
> > > Hello,
> > >
> > >
> > >
> > > @Delany, regarding 1 and 2: If I added all the other elements of the
> > > dependency tag, I would have to apply dependency management anyway if
> > > present (and I played around with it for a bit), but I see your point.
> > > Maybe using the dependency tag (I'd still name it override though) is
> > > "good
>
> enough" for small projects/POMs. I will throw a bit of time at it
>
> > > and check for "bad" implications.
> > >
> > >
> > >
> > > Making the override tag optional to have some sort of global exclusion
> > > mechanism is out of scope. Let me explain: When dependency management
> > > comes
>
> into play (in maven-resolver), it is not designed/intended to
>
> > > suddenly have no dependency at hand to work with. The dependency node in
> > > the graph already exists and the only thing that's left to do is filling
> > > it with the right information. I would have to rewrite/change that code
> > > as well. I.e. the code would have to check for a dependencyOverride with
> > > a matching original with no override. To be honest, I personally find
> > > that to be confusing. An exclusion should be explicit, because it
> > > carries
> > > a lot of weight in my opinion. The absence of an XML element should not
> > > make for an exclusion. Global excludes should exist though, just in a
> > > different way.>
> > >
> > >
> > > @Romain, I disagree that not defining the version in an override could
> > > be
> > > a source of big issues, because it would have to be defined in
> > > dependency
> > > management anyway, so it's basically there. Changing the major version
> > > is
> > > possible, even today, simply by using dependency management. It is the
> > > responsibility of the developer to provide a proper override (which is
> > > why
> > > I suggested a different name, dropinReplacement, to make the intent
> > > clearer). Still, as stated earlier, I will see what I can do. No
> > > promises
> > > though. :)
> >
> > I never said I like that but it is what it is so "it would have to be
> > defined in dependency management" is an assumption you cannot do and is
> > erroneous and I don't see us saying you can't use this override feature
> > and/or we break your project if you do so I guess we don't have much
> > choice
> > than baking it completely and not half.
> >
> > Keep in mind dependencyManagement does not behave as dependency override
> > but that it solves similar issues (controlling your dependency graph for
> > submodules since in a single module it is not that useful and excludes are
> > more straight forwards) so as an user you will want to put it in the same
> > (root? ;)) pom to keep the maintenance easy - spreading overrides in all
> > poms is not easy to handle in time, this is why mgt block beats dependency
> > for ex in multimodule projects, I don't see why it wouldn't be the same
> > for
> > overrides.
> >
> > Alternatively we can fail if we hit this case to prevent overrides in such
> > a case, can be okish in first versions maybe?
> >
> > > I agree, having 2 dependencies with the same coordinates but different
> > > versions is a common thing. But in a single Maven module maven-resolver
> > > would see to it that there's only one version on the classpath. After
> > > all,
> > > we're not talking about OSGi (thank god). It's different for multiple
> > > Maven
>
> modules though and you know it, so I won't elaborate.
>
> > Would mean you forbid overrides in packaging=pom modules, not sure it
> > would
> > be that useful to do so since you would duplicate the override in all
> > modules.
> > Makes a lot of noise compared to excludes in a depMgt block form my quick
> > tests so guess it is not the intent ;).
> >
> > > And yes, overriding the classifier (and extension/type) should be
> > > possible
> > > too. And it already is, but it needs more testing, which I'm working on.
> >
> > 👍
> >
> > > Kind regards
> > > Enno
> > >
> > >
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Monday, November 22, 2021 11:00 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > >
> > > I fear not defining the version is likely a source of big issues and
> > > worse
> > > than not having this feature at all since often, when you change the
> > > major,
>
> you change totally the dependency and the override will just not
>
> > > work. You can indeed say you must not have 2 dependencies in different
> > > versions but it is what it is and it is not that uncommon - in
> > > particular
> > > for libs (and if you want to force a single version you use dependency
> > > management). So if this feature is desired I fear it must include the
> > > version and likely manage the classifier as well to work.
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > > https://www.packtpub.com/application-development/java-ee-8-high-performa
> > > nc
> > > e
> > >
> > >
> > >
> > >
> > >
> > >
> > > Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a
> > > écrit
> > >
> > > > Hi Enno,
> > > >
> > > >
> > > >
> > > > On point 1, figuring out the order of events in a build can be
> > >
> > > challenging
> > >
> > > > for newbies since Maven is declarative. For example profiles are
> > > > resolved
> > > > early on and this is reflected by their place in the pom. Although
> > > > that's
> > > > really about config composition, having the overrides under project
> > > > could
> > > > also hint at their special nature. No strong argument to make.
> > > >
> > > >
> > > >
> > > > Point 2, you say you are following a separation of concerns, but it
> > > > seems
> > > > rather you are forcing one. By requiring dependency management the
> > > > result
> > > > is a tight coupling between stages of resolving the final dependencies
> > >
> > > (not
> > >
> > > > being self-contained, you probably *should* make dependencyOverrides a
> > > > child of dependencyManagement).
> > > > Maven doesn't require managing dependencies, but your overrides do.
> > >
> > > There's
> > >
> > > > no harm in picking up config provided by DM, but why force the
> > > > relationship? If someone wants to add an exclude at the time of an
> > > > override, frankly that should just be "not your problem". Reusing an
> > > > existing structure is surely preferable to inventing another one?
> > > > Would
> > >
> > > the
> > >
> > > > enforcer rules have to learn about your new structure?
> > > > I see why you went the path of only groupId:artifactId - you copied
> > > > the
> > > > exclusion structure. But then excluding doesn't require DM.
> > > >
> > > >
> > > >
> > > > You're right about wrapping the lists. Will you at least allow not
> > >
> > > defining
> > >
> > > > a dependency at all, aka a global exclude?
> > > >
> > > >
> > > >
> > > > Delany
> > > >
> > > >
> > > >
> > > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke
> > > > <Enno.Thieleke@holisticon.de
> > > >
> > > > wrote:
> > > > > Hi, Delany,
> > > > >
> > > > >
> > > > >
> > > > > thanks for the feedback.
> > > > >
> > > > >
> > > > >
> > > > > I get your point that management and overrides can be seen as
> > > >
> > > > independent.
> > > >
> > > > > To be honest, I'm really not picky about where in the POM overrides
> > > >
> > > > should
> > > >
> > > > > be located. I was hoping for opinions on this from others (and was
> > > > > not
> > > > > disappointed) and at least one strong opinion from the Maven core
> > > > > team.
> > > >
> > > > As
> > > >
> > > > > to why I put overrides in the management section in the first place:
> > > > simply
> > > >
> > > > > because I saw overrides as a management subject.
> > > > >
> > > > >
> > > > >
> > > > > About using the existing dependency tag to define replacements: I
> > > > > tried
> > > > > that (in a way, I still used a different tag name though). The issue
> > > > > I
> > > >
> > > > have
> > > >
> > > > > with it is that the dependency tag can also take version,
> > > > > exclusions,
> > > > > optional, etc. and I want that to be in the
> > > > > /project/dependencyManagement/dependencies section. I'm applying the
> > > > > separation of concerns principle here: overrides should simply map
> > > >
> > > > artifact
> > > >
> > > > > coordinates whereas managed dependencies are all about the right
> > >
> > > versions
> > >
> > > > > and such. Or maybe the managed dependencies should also provide the
> > > > > override information? The entire existing implementation can still
> > > > > be
> > > > > changed with little effort.
> > > > >
> > > > >
> > > > >
> > > > > I also thought about allowing 0..n overrides for one original, but I
> > > > > decided to make it a 1:1 mapping. Let me explain: First, I think it
> > > > > is
> > > > > currently not possible to have lists in POMs without a wrapping
> > >
> > > element.
> > >
> > > > > One would have to write:
> > > > >
> > > > >
> > > > >
> > > > > <!-- Simplified code for brevity -->
> > > > > <dependencyOverrides>
> > > > >
> > > > > <dependencyOverride>
> > > > >
> > > > > <original/>
> > > > > <dependencies>
> > > > >
> > > > > <dependency/>
> > > > > ...
> > > > >
> > > > > </dependencies>
> > > > >
> > > > > </dependencyOverride>
> > > > >
> > > > > </dependencyOverrides>
> > > > >
> > > > >
> > > > >
> > > > > Please correct me on this if I'm wrong. Second, I think most of the
> > >
> > > time
> > >
> > > > > people will be having 1:1 mappings anyway and with that in mind,
> > > > > having
> > > >
> > > > the
> > > >
> > > > > need to use lists which require a wrapping element would bloat a
> > > > > POM.
> > > > >
> > > > >
> > > > >
> > > > > Long story short, your first point is up for discussion. If more
> > > > > people
> > > > > want overrides located elsewhere, then that's fine by me. Regarding
> > >
> > > your
> > >
> > > > > second point, I think the current approach is good and people would
> > >
> > > have
> > >
> > > > to
> > > >
> > > > > provide strong arguments to convince me of a different approach.
> > > > >
> > > > >
> > > > >
> > > > > Again, thanks for the feedback, it's really appreciated and if you
> > > > > have
> > > > > more, please let me know.
> > > > >
> > > > >
> > > > >
> > > > > Kind regards,
> > > > > Enno
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Delany <de...@gmail.com>
> > > > > Sent: Sunday, November 21, 2021 4:46 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > >
> > > > >
> > > > > Hi Enno,
> > > > >
> > > > >
> > > > >
> > > > > 2 things. I'd want to emphasise that the resolution of dependency
> > > > > management info and the dependency overrides (more like a reactor
> > > > > management concern) are independent of one another. Can achieve by
> > > > > promoting the tag to project.
> > > > >
> > > > >
> > > > >
> > > > > Then why not use the existing dependency tag to define the
> > > >
> > > > replacement(s).
> > > >
> > > > > Accept 0, 1 or many.
> > > > >
> > > > >
> > > > >
> > > > > ...
> > > > > <groupId>a</groupId>
> > > > > <artifactId>a</artifactId>
> > > > > <dependencyOverrides>
> > > > >
> > > > > <dependencyOverride>
> > > > >
> > > > > <original>
> > > > >
> > > > > <groupId>y</groupId>
> > > > > <artifactId>y</artifactId>
> > > > >
> > > > > </original>
> > > > > <dependency>
> > > > >
> > > > > <groupId>z</groupId>
> > > > > <artifactId>z</artifactId>
> > > > >
> > > > > </dependency>
> > > > > <dependency>
> > > > >
> > > > > <groupId>q</groupId>
> > > > > <artifactId>q</artifactId>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > </dependencyOverride>
> > > > >
> > > > > </dependencyOverrides>
> > > > > <dependencies>
> > > > >
> > > > > <dependency>
> > > > >
> > > > > <groupId>w</groupId>
> > > > > <artifactId>w</artifactId>
> > > > >
> > > > > </dependency>
> > > > > <dependency>
> > > > >
> > > > > <groupId>x</groupId>
> > > > > <artifactId>x</artifactId>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > </dependencies>
> > > > > ...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Delany
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> > >
> > > Enno.Thieleke@holisticon.de
> > >
> > > > > wrote:
> > > > > > Hello,
> > > > > >
> > > > > >
> > > > > >
> > > > > > it's been a while and I've made some progress regarding
> > > > > > overrides/replacements and wanted to share the current state.
> > > > > >
> > > > > > What's implemented/changed:
> > > > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > > >
> > > > > > /project/dependencyManagement/dependencyOverrides which in turn
> > > > > > can
> > > >
> > > > take
> > > >
> > > > > > the coordinates of original and overriding artifacts.
> > > > > >
> > > > > > * Overrides can be declared on any POM level in a hierarchy
> > > > > > POMs
> > > > >
> > > > > (i.e.
> > > > >
> > > > > > parents and children.
> > > > > >
> > > > > > * Overrides can be imported from other POMs using the existing
> > > > > >
> > > > > > `import` scope for POMs in the dependencyManagement section.
> > > > > >
> > > > > > * If the same original artifact is overridden on different
> > >
> > > levels,
> > >
> > > > > the
> > > > >
> > > > > > "most downstream" wins.
> > > > > >
> > > > > > * An override *must* be accompanied by an entry in the
> > > > > >
> > > > > > dependencyManagement section. Maven generates an error and halts,
> > > > > > if
> > > > >
> > > > > that's
> > > > >
> > > > > > not the case.
> > > > > >
> > > > > > * If an override is declared and consumed in the same
> > > > > > effective
> > > >
> > > > POM,
> > > >
> > > > > > Maven generates a warning that the user should use the overriding
> > > > >
> > > > > artifact
> > > > >
> > > > > > instead of the original artifact.
> > > > > >
> > > > > > * The dependencies of an effective POM remain untouched.
> > >
> > > Overrides
> > >
> > > > > are
> > > > >
> > > > > > declared in POMs, but the act of overriding is implemented in
> > > > > > maven-resolver.
> > > > > >
> > > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT,
> > > > > > because
> > > > > >
> > > > > > interfaces needed additions. While some might consider this to be
> > > > > > a
> > > >
> > > > minor
> > > >
> > > > > > change, I consider this to be a major change, because the
> > > > > > interfaces
> > > >
> > > > are
> > > >
> > > > > > not (and cannot be, yet) sealed.
> > > > > >
> > > > > > * It is possible to override overrides of transitive
> > >
> > > dependencies.
> > >
> > > > In
> > > >
> > > > > > other words, it is possible to override overrides of POMs of
> > > > >
> > > > > dependencies.
> > > > >
> > > > > > While working on this I thought about names for
> > >
> > > overrides/replacements.
> > >
> > > > > > I'm still open to suggestions and pretty much undecided. Another
> > > > > > name
> > > > >
> > > > > that
> > > > >
> > > > > > popped into my head is `dropinReplacements`, because it makes the
> > > >
> > > > intent
> > > >
> > > > > > very clear.
> > > > > >
> > > > > >
> > > > > >
> > > > > > For those of you who are interested, here are the links to the
> > > > > > code
> > > >
> > > > again
> > > >
> > > > > > (so it's just one click away):
> > > > > > *
> > > > >
> > > > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > >
> > > > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > > > *
> > > > > > https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > > > >
> > > > > > Also, I've rebased my changes onto master very recently.
> > >
> > > > > > And here's the proposal itself:
> > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > er
> > > rides.md
> > >
> > > > > > If you find the time to look, please let me know what you think
> > > > > > and
> > > >
> > > > what
> > > >
> > > > > > you think is missing.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > >
> > > > > > A few notes on the proposal:
> > > > > > - Leave a dependency graph virtually untouched.
> > > > > > Only change/override nodes in place. Don't exclude dependencies
> > >
> > > and
> > >
> > > > > > include new ones on a different level in the graph.
> > > > > >
> > > > > > Think, whatever it means, served dependencies in mojo shouldnt
> > > > > > have
> > >
> > > to
> > >
> > > > > rely
> > > > >
> > > > > > on this new section using getXArtifact or dependency visitor. No
> > > > > > real
> > > > >
> > > > > good
> > > > >
> > > > > > reason to break everyone there.
> > > > > >
> > > > > >
> > > > > >
> > > > > > A not used override must break the build (it is an unexpected bug
> > > > > > and
> > > > >
> > > > > would
> > > > >
> > > > > > make the dev life hard otherwise). I perfectly see that it will
> > > > > > break
> > > > > > building a submodule in several cases but otherwise the section
> > > > > > will
> > > > >
> > > > > become
> > > > >
> > > > > > unmanageable with time (see hibernate or cxf example) and since
> > > > > > you
> > > >
> > > > loose
> > > >
> > > > > > the dependency relationship with this option compared to
> > > > > > exclusions,
> > >
> > > it
> > >
> > > > > way
> > > > >
> > > > > > too much work to maintain it in practise. (This is why I think it
> > > > >
> > > > > shouldnt
> > > > >
> > > > > > be done this way but very worse case at dependency level giving
> > > > > > hints
> > > >
> > > > for
> > > >
> > > > > > overrides and not elsewhere, mixed with dependency managementnit
> > > > > > is
> > > > >
> > > > > trivial
> > > > >
> > > > > > to handle and maintain then).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pom rewriter must handle this section by dropping it and replacing
> > > > > > it
> > > >
> > > > by
> > > >
> > > > > > exludes to keep compatibility with 3rd party resolvers
> > > > > > (deployment).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Overall, I still think it would be neat to see it as an extension
> > > > > > for
> > > > >
> > > > > maven
> > > > >
> > > > > > 3.8.2 or 4 to be testable and validate design choices and actual
> > >
> > > usage
> > >
> > > > on
> > > >
> > > > > > real dependencies compared to current option.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > > >
> > > > Enno.Thieleke@holisticon.de
> > > >
> > > > > > a
> > > > > >
> > > > > > écrit :
> > > > > > > Hello again,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I tried to create a proposal in/under
> > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > >
> > > > > > ,
> > > > > >
> > > > > > > but I'm not allowed to, which makes sense since I'm new to the
> > >
> > > wiki,
> > >
> > > > > so I
> > > > >
> > > > > > > committed a proposal to my fork:
> > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > er
> > > rides.md
> > >
> > > > > > > The current version probably still contains errors and misses
> > >
> > > details
> > >
> > > > > but
> > > > >
> > > > > > > I imo they need to be worked out in a group effort.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Some feedback/comments would be appreciated.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Maybe you could create a proposal page in your wiki and grant me
> > >
> > > edit
> > >
> > > > > > > rights (user eth)?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Michael,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Just a few more questions before I start.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > For the issue: Would reopening
> > > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> > >
> > > you
> > >
> > > > > like
> > > > >
> > > > > > > to see a new one?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Where do I create the proposal?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > What should be created first, the issue or the proposal? I'm
> > >
> > > asking,
> > >
> > > > > > > because in the proposal we'd work out the details and after
> > > > > > > that's
> > > > >
> > > > > done,
> > > > >
> > > > > > > that's where the issue becomes relevant (no issue, no code
> > >
> > > changes).
> > >
> > > > At
> > > >
> > > > > > > least that's how I'm used to implementing changes like this. I
> > >
> > > don't
> > >
> > > > > want
> > > > >
> > > > > > > to have created unnecessary noise in your issue system, if - for
> > >
> > > some
> > >
> > > > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Is it ok to use one issue for changes in both projects, Maven
> > > > > > > and
> > > > > > > maven-resolver?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > > ________________________________
> > > > > > > From: Michael Osipov <mi...@apache.org>
> > > > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <En...@holisticon.de>
> > Sent: Friday, December 3, 2021 10:54 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi,
> >
> > concerning the request to change the override XML element to a
> > fully-fledged dependency, thus removing the need for accompanying managed
> > dependencies...
> >
> > tl;dr
> > I would add a version attribute, nothing more, to the override XML
> > element.
> > The rest would remain unchanged.
> >
> > Full version:
> >
> > If I turned the override XML element into a fully-fledged dependency,
> > should we support properties such as `scope` and `optional`? In my
> > opinion we shouldn't, because that's still subject to original dependency
> > definitions, not overrides. If people want to change the scope or add
> > exclusions, they should stick to dependency management. That's what it's
> > there for.
> I think
>
> > it's enough to just add a version child-element to the current override
> > XML
> > element. That would remove the need for accompanying managed dependencies
> > for just versions and in many simple cases that'd suffice, wouldn't you
> > agree? I think we should draw the line here between changing artifact
> > coordinates, a special kind of dependency management, and managing other
> > dependency properties -> separation of concerns. Suppose I added a version
> > child-element, I'd still have concerns about moving dependencyOverrides up
> > one level so that it would be a sibling of dependencyManagement. Imagine I
> > moved dependencyOverrides up one level. How would we import them properly?
> > Currently importing a POM imports both: managed dependencies as well as
> > overrides and I think that wouldn't be the right approach anymore. Would
> > special import XML elements do the trick? Such as this:
> > <dependencyManagement>
> >
> > <dependencies>
> >
> > <dependency>
> >
> > ...
> > <scope>import</scope> <!-- Imports managed dependencies -->
> >
> > </dependency>
> >
> > </dependencies>
> >
> > </dependencyManagement>
> > <dependencyOverrides>
> >
> > <imports>
> >
> > <import> <!-- Imports overrides; the packaging of the import MUST be
> > pom
> >
> > -->
>
> <groupId/>
>
> > <artifactId/>
> > <version/>
> >
> > </import>
> >
> > </imports>
> > ...
> >
> > </dependencyOverrides>
> >
> > To be honest: I think that'd suck. Another way would be to introduce a new
> > special purpose scope, but I think the existing special purpose scope
> > "import" is perfect: it's meant to import dependency management
> > information
> > from different POMs and since overrides affect dependencies in the sense
> > that they manage dependency coordinates, we're still talking about
> > dependency management.
> >
> > Please let me know what you think.
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Monday, November 22, 2021 2:33 PM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de>
> > a
> >
> > écrit :
> > > Hello,
> > >
> > >
> > >
> > > @Delany, regarding 1 and 2: If I added all the other elements of the
> > > dependency tag, I would have to apply dependency management anyway if
> > > present (and I played around with it for a bit), but I see your point.
> > > Maybe using the dependency tag (I'd still name it override though) is
> > > "good
>
> enough" for small projects/POMs. I will throw a bit of time at it
>
> > > and check for "bad" implications.
> > >
> > >
> > >
> > > Making the override tag optional to have some sort of global exclusion
> > > mechanism is out of scope. Let me explain: When dependency management
> > > comes
>
> into play (in maven-resolver), it is not designed/intended to
>
> > > suddenly have no dependency at hand to work with. The dependency node in
> > > the graph already exists and the only thing that's left to do is filling
> > > it with the right information. I would have to rewrite/change that code
> > > as well. I.e. the code would have to check for a dependencyOverride with
> > > a matching original with no override. To be honest, I personally find
> > > that to be confusing. An exclusion should be explicit, because it
> > > carries
> > > a lot of weight in my opinion. The absence of an XML element should not
> > > make for an exclusion. Global excludes should exist though, just in a
> > > different way.>
> > >
> > >
> > > @Romain, I disagree that not defining the version in an override could
> > > be
> > > a source of big issues, because it would have to be defined in
> > > dependency
> > > management anyway, so it's basically there. Changing the major version
> > > is
> > > possible, even today, simply by using dependency management. It is the
> > > responsibility of the developer to provide a proper override (which is
> > > why
> > > I suggested a different name, dropinReplacement, to make the intent
> > > clearer). Still, as stated earlier, I will see what I can do. No
> > > promises
> > > though. :)
> >
> > I never said I like that but it is what it is so "it would have to be
> > defined in dependency management" is an assumption you cannot do and is
> > erroneous and I don't see us saying you can't use this override feature
> > and/or we break your project if you do so I guess we don't have much
> > choice
> > than baking it completely and not half.
> >
> > Keep in mind dependencyManagement does not behave as dependency override
> > but that it solves similar issues (controlling your dependency graph for
> > submodules since in a single module it is not that useful and excludes are
> > more straight forwards) so as an user you will want to put it in the same
> > (root? ;)) pom to keep the maintenance easy - spreading overrides in all
> > poms is not easy to handle in time, this is why mgt block beats dependency
> > for ex in multimodule projects, I don't see why it wouldn't be the same
> > for
> > overrides.
> >
> > Alternatively we can fail if we hit this case to prevent overrides in such
> > a case, can be okish in first versions maybe?
> >
> > > I agree, having 2 dependencies with the same coordinates but different
> > > versions is a common thing. But in a single Maven module maven-resolver
> > > would see to it that there's only one version on the classpath. After
> > > all,
> > > we're not talking about OSGi (thank god). It's different for multiple
> > > Maven
>
> modules though and you know it, so I won't elaborate.
>
> > Would mean you forbid overrides in packaging=pom modules, not sure it
> > would
> > be that useful to do so since you would duplicate the override in all
> > modules.
> > Makes a lot of noise compared to excludes in a depMgt block form my quick
> > tests so guess it is not the intent ;).
> >
> > > And yes, overriding the classifier (and extension/type) should be
> > > possible
> > > too. And it already is, but it needs more testing, which I'm working on.
> >
> > 👍
> >
> > > Kind regards
> > > Enno
> > >
> > >
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Monday, November 22, 2021 11:00 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > >
> > > I fear not defining the version is likely a source of big issues and
> > > worse
> > > than not having this feature at all since often, when you change the
> > > major,
>
> you change totally the dependency and the override will just not
>
> > > work. You can indeed say you must not have 2 dependencies in different
> > > versions but it is what it is and it is not that uncommon - in
> > > particular
> > > for libs (and if you want to force a single version you use dependency
> > > management). So if this feature is desired I fear it must include the
> > > version and likely manage the classifier as well to work.
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > > https://www.packtpub.com/application-development/java-ee-8-high-performa
> > > nc
> > > e
> > >
> > >
> > >
> > >
> > >
> > >
> > > Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a
> > > écrit
> > >
> > > > Hi Enno,
> > > >
> > > >
> > > >
> > > > On point 1, figuring out the order of events in a build can be
> > >
> > > challenging
> > >
> > > > for newbies since Maven is declarative. For example profiles are
> > > > resolved
> > > > early on and this is reflected by their place in the pom. Although
> > > > that's
> > > > really about config composition, having the overrides under project
> > > > could
> > > > also hint at their special nature. No strong argument to make.
> > > >
> > > >
> > > >
> > > > Point 2, you say you are following a separation of concerns, but it
> > > > seems
> > > > rather you are forcing one. By requiring dependency management the
> > > > result
> > > > is a tight coupling between stages of resolving the final dependencies
> > >
> > > (not
> > >
> > > > being self-contained, you probably *should* make dependencyOverrides a
> > > > child of dependencyManagement).
> > > > Maven doesn't require managing dependencies, but your overrides do.
> > >
> > > There's
> > >
> > > > no harm in picking up config provided by DM, but why force the
> > > > relationship? If someone wants to add an exclude at the time of an
> > > > override, frankly that should just be "not your problem". Reusing an
> > > > existing structure is surely preferable to inventing another one?
> > > > Would
> > >
> > > the
> > >
> > > > enforcer rules have to learn about your new structure?
> > > > I see why you went the path of only groupId:artifactId - you copied
> > > > the
> > > > exclusion structure. But then excluding doesn't require DM.
> > > >
> > > >
> > > >
> > > > You're right about wrapping the lists. Will you at least allow not
> > >
> > > defining
> > >
> > > > a dependency at all, aka a global exclude?
> > > >
> > > >
> > > >
> > > > Delany
> > > >
> > > >
> > > >
> > > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke
> > > > <Enno.Thieleke@holisticon.de
> > > >
> > > > wrote:
> > > > > Hi, Delany,
> > > > >
> > > > >
> > > > >
> > > > > thanks for the feedback.
> > > > >
> > > > >
> > > > >
> > > > > I get your point that management and overrides can be seen as
> > > >
> > > > independent.
> > > >
> > > > > To be honest, I'm really not picky about where in the POM overrides
> > > >
> > > > should
> > > >
> > > > > be located. I was hoping for opinions on this from others (and was
> > > > > not
> > > > > disappointed) and at least one strong opinion from the Maven core
> > > > > team.
> > > >
> > > > As
> > > >
> > > > > to why I put overrides in the management section in the first place:
> > > > simply
> > > >
> > > > > because I saw overrides as a management subject.
> > > > >
> > > > >
> > > > >
> > > > > About using the existing dependency tag to define replacements: I
> > > > > tried
> > > > > that (in a way, I still used a different tag name though). The issue
> > > > > I
> > > >
> > > > have
> > > >
> > > > > with it is that the dependency tag can also take version,
> > > > > exclusions,
> > > > > optional, etc. and I want that to be in the
> > > > > /project/dependencyManagement/dependencies section. I'm applying the
> > > > > separation of concerns principle here: overrides should simply map
> > > >
> > > > artifact
> > > >
> > > > > coordinates whereas managed dependencies are all about the right
> > >
> > > versions
> > >
> > > > > and such. Or maybe the managed dependencies should also provide the
> > > > > override information? The entire existing implementation can still
> > > > > be
> > > > > changed with little effort.
> > > > >
> > > > >
> > > > >
> > > > > I also thought about allowing 0..n overrides for one original, but I
> > > > > decided to make it a 1:1 mapping. Let me explain: First, I think it
> > > > > is
> > > > > currently not possible to have lists in POMs without a wrapping
> > >
> > > element.
> > >
> > > > > One would have to write:
> > > > >
> > > > >
> > > > >
> > > > > <!-- Simplified code for brevity -->
> > > > > <dependencyOverrides>
> > > > >
> > > > > <dependencyOverride>
> > > > >
> > > > > <original/>
> > > > > <dependencies>
> > > > >
> > > > > <dependency/>
> > > > > ...
> > > > >
> > > > > </dependencies>
> > > > >
> > > > > </dependencyOverride>
> > > > >
> > > > > </dependencyOverrides>
> > > > >
> > > > >
> > > > >
> > > > > Please correct me on this if I'm wrong. Second, I think most of the
> > >
> > > time
> > >
> > > > > people will be having 1:1 mappings anyway and with that in mind,
> > > > > having
> > > >
> > > > the
> > > >
> > > > > need to use lists which require a wrapping element would bloat a
> > > > > POM.
> > > > >
> > > > >
> > > > >
> > > > > Long story short, your first point is up for discussion. If more
> > > > > people
> > > > > want overrides located elsewhere, then that's fine by me. Regarding
> > >
> > > your
> > >
> > > > > second point, I think the current approach is good and people would
> > >
> > > have
> > >
> > > > to
> > > >
> > > > > provide strong arguments to convince me of a different approach.
> > > > >
> > > > >
> > > > >
> > > > > Again, thanks for the feedback, it's really appreciated and if you
> > > > > have
> > > > > more, please let me know.
> > > > >
> > > > >
> > > > >
> > > > > Kind regards,
> > > > > Enno
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Delany <de...@gmail.com>
> > > > > Sent: Sunday, November 21, 2021 4:46 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > >
> > > > >
> > > > > Hi Enno,
> > > > >
> > > > >
> > > > >
> > > > > 2 things. I'd want to emphasise that the resolution of dependency
> > > > > management info and the dependency overrides (more like a reactor
> > > > > management concern) are independent of one another. Can achieve by
> > > > > promoting the tag to project.
> > > > >
> > > > >
> > > > >
> > > > > Then why not use the existing dependency tag to define the
> > > >
> > > > replacement(s).
> > > >
> > > > > Accept 0, 1 or many.
> > > > >
> > > > >
> > > > >
> > > > > ...
> > > > > <groupId>a</groupId>
> > > > > <artifactId>a</artifactId>
> > > > > <dependencyOverrides>
> > > > >
> > > > > <dependencyOverride>
> > > > >
> > > > > <original>
> > > > >
> > > > > <groupId>y</groupId>
> > > > > <artifactId>y</artifactId>
> > > > >
> > > > > </original>
> > > > > <dependency>
> > > > >
> > > > > <groupId>z</groupId>
> > > > > <artifactId>z</artifactId>
> > > > >
> > > > > </dependency>
> > > > > <dependency>
> > > > >
> > > > > <groupId>q</groupId>
> > > > > <artifactId>q</artifactId>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > </dependencyOverride>
> > > > >
> > > > > </dependencyOverrides>
> > > > > <dependencies>
> > > > >
> > > > > <dependency>
> > > > >
> > > > > <groupId>w</groupId>
> > > > > <artifactId>w</artifactId>
> > > > >
> > > > > </dependency>
> > > > > <dependency>
> > > > >
> > > > > <groupId>x</groupId>
> > > > > <artifactId>x</artifactId>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > </dependencies>
> > > > > ...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Delany
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> > >
> > > Enno.Thieleke@holisticon.de
> > >
> > > > > wrote:
> > > > > > Hello,
> > > > > >
> > > > > >
> > > > > >
> > > > > > it's been a while and I've made some progress regarding
> > > > > > overrides/replacements and wanted to share the current state.
> > > > > >
> > > > > > What's implemented/changed:
> > > > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > > >
> > > > > > /project/dependencyManagement/dependencyOverrides which in turn
> > > > > > can
> > > >
> > > > take
> > > >
> > > > > > the coordinates of original and overriding artifacts.
> > > > > >
> > > > > > * Overrides can be declared on any POM level in a hierarchy
> > > > > > POMs
> > > > >
> > > > > (i.e.
> > > > >
> > > > > > parents and children.
> > > > > >
> > > > > > * Overrides can be imported from other POMs using the existing
> > > > > >
> > > > > > `import` scope for POMs in the dependencyManagement section.
> > > > > >
> > > > > > * If the same original artifact is overridden on different
> > >
> > > levels,
> > >
> > > > > the
> > > > >
> > > > > > "most downstream" wins.
> > > > > >
> > > > > > * An override *must* be accompanied by an entry in the
> > > > > >
> > > > > > dependencyManagement section. Maven generates an error and halts,
> > > > > > if
> > > > >
> > > > > that's
> > > > >
> > > > > > not the case.
> > > > > >
> > > > > > * If an override is declared and consumed in the same
> > > > > > effective
> > > >
> > > > POM,
> > > >
> > > > > > Maven generates a warning that the user should use the overriding
> > > > >
> > > > > artifact
> > > > >
> > > > > > instead of the original artifact.
> > > > > >
> > > > > > * The dependencies of an effective POM remain untouched.
> > >
> > > Overrides
> > >
> > > > > are
> > > > >
> > > > > > declared in POMs, but the act of overriding is implemented in
> > > > > > maven-resolver.
> > > > > >
> > > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT,
> > > > > > because
> > > > > >
> > > > > > interfaces needed additions. While some might consider this to be
> > > > > > a
> > > >
> > > > minor
> > > >
> > > > > > change, I consider this to be a major change, because the
> > > > > > interfaces
> > > >
> > > > are
> > > >
> > > > > > not (and cannot be, yet) sealed.
> > > > > >
> > > > > > * It is possible to override overrides of transitive
> > >
> > > dependencies.
> > >
> > > > In
> > > >
> > > > > > other words, it is possible to override overrides of POMs of
> > > > >
> > > > > dependencies.
> > > > >
> > > > > > While working on this I thought about names for
> > >
> > > overrides/replacements.
> > >
> > > > > > I'm still open to suggestions and pretty much undecided. Another
> > > > > > name
> > > > >
> > > > > that
> > > > >
> > > > > > popped into my head is `dropinReplacements`, because it makes the
> > > >
> > > > intent
> > > >
> > > > > > very clear.
> > > > > >
> > > > > >
> > > > > >
> > > > > > For those of you who are interested, here are the links to the
> > > > > > code
> > > >
> > > > again
> > > >
> > > > > > (so it's just one click away):
> > > > > > *
> > > > >
> > > > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > >
> > > > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > > > *
> > > > > > https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > > > >
> > > > > > Also, I've rebased my changes onto master very recently.
> > >
> > > > > > And here's the proposal itself:
> > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > er
> > > rides.md
> > >
> > > > > > If you find the time to look, please let me know what you think
> > > > > > and
> > > >
> > > > what
> > > >
> > > > > > you think is missing.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > >
> > > > > > A few notes on the proposal:
> > > > > > - Leave a dependency graph virtually untouched.
> > > > > > Only change/override nodes in place. Don't exclude dependencies
> > >
> > > and
> > >
> > > > > > include new ones on a different level in the graph.
> > > > > >
> > > > > > Think, whatever it means, served dependencies in mojo shouldnt
> > > > > > have
> > >
> > > to
> > >
> > > > > rely
> > > > >
> > > > > > on this new section using getXArtifact or dependency visitor. No
> > > > > > real
> > > > >
> > > > > good
> > > > >
> > > > > > reason to break everyone there.
> > > > > >
> > > > > >
> > > > > >
> > > > > > A not used override must break the build (it is an unexpected bug
> > > > > > and
> > > > >
> > > > > would
> > > > >
> > > > > > make the dev life hard otherwise). I perfectly see that it will
> > > > > > break
> > > > > > building a submodule in several cases but otherwise the section
> > > > > > will
> > > > >
> > > > > become
> > > > >
> > > > > > unmanageable with time (see hibernate or cxf example) and since
> > > > > > you
> > > >
> > > > loose
> > > >
> > > > > > the dependency relationship with this option compared to
> > > > > > exclusions,
> > >
> > > it
> > >
> > > > > way
> > > > >
> > > > > > too much work to maintain it in practise. (This is why I think it
> > > > >
> > > > > shouldnt
> > > > >
> > > > > > be done this way but very worse case at dependency level giving
> > > > > > hints
> > > >
> > > > for
> > > >
> > > > > > overrides and not elsewhere, mixed with dependency managementnit
> > > > > > is
> > > > >
> > > > > trivial
> > > > >
> > > > > > to handle and maintain then).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pom rewriter must handle this section by dropping it and replacing
> > > > > > it
> > > >
> > > > by
> > > >
> > > > > > exludes to keep compatibility with 3rd party resolvers
> > > > > > (deployment).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Overall, I still think it would be neat to see it as an extension
> > > > > > for
> > > > >
> > > > > maven
> > > > >
> > > > > > 3.8.2 or 4 to be testable and validate design choices and actual
> > >
> > > usage
> > >
> > > > on
> > > >
> > > > > > real dependencies compared to current option.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > > >
> > > > Enno.Thieleke@holisticon.de
> > > >
> > > > > > a
> > > > > >
> > > > > > écrit :
> > > > > > > Hello again,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I tried to create a proposal in/under
> > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > >
> > > > > > ,
> > > > > >
> > > > > > > but I'm not allowed to, which makes sense since I'm new to the
> > >
> > > wiki,
> > >
> > > > > so I
> > > > >
> > > > > > > committed a proposal to my fork:
> > > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Ov
> > > er
> > > rides.md
> > >
> > > > > > > The current version probably still contains errors and misses
> > >
> > > details
> > >
> > > > > but
> > > > >
> > > > > > > I imo they need to be worked out in a group effort.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Some feedback/comments would be appreciated.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Maybe you could create a proposal page in your wiki and grant me
> > >
> > > edit
> > >
> > > > > > > rights (user eth)?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Michael,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Just a few more questions before I start.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > For the issue: Would reopening
> > > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> > >
> > > you
> > >
> > > > > like
> > > > >
> > > > > > > to see a new one?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Where do I create the proposal?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > What should be created first, the issue or the proposal? I'm
> > >
> > > asking,
> > >
> > > > > > > because in the proposal we'd work out the details and after
> > > > > > > that's
> > > > >
> > > > > done,
> > > > >
> > > > > > > that's where the issue becomes relevant (no issue, no code
> > >
> > > changes).
> > >
> > > > At
> > > >
> > > > > > > least that's how I'm used to implementing changes like this. I
> > >
> > > don't
> > >
> > > > > want
> > > > >
> > > > > > > to have created unnecessary noise in your issue system, if - for
> > >
> > > some
> > >
> > > > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Is it ok to use one issue for changes in both projects, Maven
> > > > > > > and
> > > > > > > maven-resolver?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Enno
> > > > > > > ________________________________
> > > > > > > From: Michael Osipov <mi...@apache.org>
> > > > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Hervé BOUTEMY <he...@free.fr>.
my own quick opinion:
1. I did not review the full email thread, so is https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.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 <En...@holisticon.de>
> Sent: Friday, December 3, 2021 10:54 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi,
>
> concerning the request to change the override XML element to a fully-fledged
> dependency, thus removing the need for accompanying managed
> dependencies...
> tl;dr
> I would add a version attribute, nothing more, to the override XML element.
> The rest would remain unchanged.
> Full version:
>
> If I turned the override XML element into a fully-fledged dependency, should
> we support properties such as `scope` and `optional`? In my opinion we
> shouldn't, because that's still subject to original dependency definitions,
> not overrides. If people want to change the scope or add exclusions, they
> should stick to dependency management. That's what it's there for.
I think
> it's enough to just add a version child-element to the current override XML
> element. That would remove the need for accompanying managed dependencies
> for just versions and in many simple cases that'd suffice, wouldn't you
> agree? I think we should draw the line here between changing artifact
> coordinates, a special kind of dependency management, and managing other
> dependency properties -> separation of concerns. Suppose I added a version
> child-element, I'd still have concerns about moving dependencyOverrides up
> one level so that it would be a sibling of dependencyManagement. Imagine I
> moved dependencyOverrides up one level. How would we import them properly?
> Currently importing a POM imports both: managed dependencies as well as
> overrides and I think that wouldn't be the right approach anymore. Would
> special import XML elements do the trick? Such as this:
> <dependencyManagement>
> <dependencies>
> <dependency>
> ...
> <scope>import</scope> <!-- Imports managed dependencies -->
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencyOverrides>
> <imports>
> <import> <!-- Imports overrides; the packaging of the import MUST be pom
> -->
<groupId/>
> <artifactId/>
> <version/>
> </import>
> </imports>
> ...
> </dependencyOverrides>
>
> To be honest: I think that'd suck. Another way would be to introduce a new
> special purpose scope, but I think the existing special purpose scope
> "import" is perfect: it's meant to import dependency management information
> from different POMs and since overrides affect dependencies in the sense
> that they manage dependency coordinates, we're still talking about
> dependency management.
> Please let me know what you think.
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Monday, November 22, 2021 2:33 PM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de> a
> écrit :
>
>
> > Hello,
> >
> >
> >
> > @Delany, regarding 1 and 2: If I added all the other elements of the
> > dependency tag, I would have to apply dependency management anyway if
> > present (and I played around with it for a bit), but I see your point.
> > Maybe using the dependency tag (I'd still name it override though) is
> > "good
enough" for small projects/POMs. I will throw a bit of time at it
> > and check for "bad" implications.
> >
> >
> >
> > Making the override tag optional to have some sort of global exclusion
> > mechanism is out of scope. Let me explain: When dependency management
> > comes
into play (in maven-resolver), it is not designed/intended to
> > suddenly have no dependency at hand to work with. The dependency node in
> > the graph already exists and the only thing that's left to do is filling
> > it with the right information. I would have to rewrite/change that code
> > as well. I.e. the code would have to check for a dependencyOverride with
> > a matching original with no override. To be honest, I personally find
> > that to be confusing. An exclusion should be explicit, because it carries
> > a lot of weight in my opinion. The absence of an XML element should not
> > make for an exclusion. Global excludes should exist though, just in a
> > different way.>
> >
> >
> > @Romain, I disagree that not defining the version in an override could be
> > a source of big issues, because it would have to be defined in dependency
> > management anyway, so it's basically there. Changing the major version is
> > possible, even today, simply by using dependency management. It is the
> > responsibility of the developer to provide a proper override (which is
> > why
> > I suggested a different name, dropinReplacement, to make the intent
> > clearer). Still, as stated earlier, I will see what I can do. No promises
> > though. :)
> >
> >
>
>
> I never said I like that but it is what it is so "it would have to be
> defined in dependency management" is an assumption you cannot do and is
> erroneous and I don't see us saying you can't use this override feature
> and/or we break your project if you do so I guess we don't have much choice
> than baking it completely and not half.
>
> Keep in mind dependencyManagement does not behave as dependency override
> but that it solves similar issues (controlling your dependency graph for
> submodules since in a single module it is not that useful and excludes are
> more straight forwards) so as an user you will want to put it in the same
> (root? ;)) pom to keep the maintenance easy - spreading overrides in all
> poms is not easy to handle in time, this is why mgt block beats dependency
> for ex in multimodule projects, I don't see why it wouldn't be the same for
> overrides.
>
> Alternatively we can fail if we hit this case to prevent overrides in such
> a case, can be okish in first versions maybe?
>
>
>
> >
> >
> > I agree, having 2 dependencies with the same coordinates but different
> > versions is a common thing. But in a single Maven module maven-resolver
> > would see to it that there's only one version on the classpath. After
> > all,
> > we're not talking about OSGi (thank god). It's different for multiple
> > Maven
modules though and you know it, so I won't elaborate.
> >
> >
>
>
> Would mean you forbid overrides in packaging=pom modules, not sure it would
> be that useful to do so since you would duplicate the override in all
> modules.
> Makes a lot of noise compared to excludes in a depMgt block form my quick
> tests so guess it is not the intent ;).
>
>
>
> >
> >
> > And yes, overriding the classifier (and extension/type) should be
> > possible
> > too. And it already is, but it needs more testing, which I'm working on.
> >
> >
>
>
> 👍
>
>
>
> >
> >
> > Kind regards
> > Enno
> >
> >
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Monday, November 22, 2021 11:00 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> >
> >
> > Hi all,
> >
> >
> >
> > I fear not defining the version is likely a source of big issues and
> > worse
> > than not having this feature at all since often, when you change the
> > major,
you change totally the dependency and the override will just not
> > work. You can indeed say you must not have 2 dependencies in different
> > versions but it is what it is and it is not that uncommon - in particular
> > for libs (and if you want to force a single version you use dependency
> > management). So if this feature is desired I fear it must include the
> > version and likely manage the classifier as well to work.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
>
> > >
> >
> >
> >
> >
> > Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a écrit
> >
> > :
> >
> >
> >
> > > Hi Enno,
> > >
> > >
> > >
> > > On point 1, figuring out the order of events in a build can be
> >
> > challenging
> >
> > > for newbies since Maven is declarative. For example profiles are
> > > resolved
> > > early on and this is reflected by their place in the pom. Although
> > > that's
> > > really about config composition, having the overrides under project
> > > could
> > > also hint at their special nature. No strong argument to make.
> > >
> > >
> > >
> > > Point 2, you say you are following a separation of concerns, but it
> > > seems
> > > rather you are forcing one. By requiring dependency management the
> > > result
> > > is a tight coupling between stages of resolving the final dependencies
> >
> > (not
> >
> > > being self-contained, you probably *should* make dependencyOverrides a
> > > child of dependencyManagement).
> > > Maven doesn't require managing dependencies, but your overrides do.
> >
> > There's
> >
> > > no harm in picking up config provided by DM, but why force the
> > > relationship? If someone wants to add an exclude at the time of an
> > > override, frankly that should just be "not your problem". Reusing an
> > > existing structure is surely preferable to inventing another one? Would
> >
> > the
> >
> > > enforcer rules have to learn about your new structure?
> > > I see why you went the path of only groupId:artifactId - you copied the
> > > exclusion structure. But then excluding doesn't require DM.
> > >
> > >
> > >
> > > You're right about wrapping the lists. Will you at least allow not
> >
> > defining
> >
> > > a dependency at all, aka a global exclude?
> > >
> > >
> > >
> > > Delany
> > >
> > >
> > >
> > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke
> > > <Enno.Thieleke@holisticon.de
> > >
> > >
> > >
> > > wrote:
> > >
> > >
> > >
> > > > Hi, Delany,
> > > >
> > > >
> > > >
> > > > thanks for the feedback.
> > > >
> > > >
> > > >
> > > > I get your point that management and overrides can be seen as
> > >
> > > independent.
> > >
> > > > To be honest, I'm really not picky about where in the POM overrides
> > >
> > > should
> > >
> > > > be located. I was hoping for opinions on this from others (and was
> > > > not
> > > > disappointed) and at least one strong opinion from the Maven core
> > > > team.
> > >
> > > As
> > >
> > > > to why I put overrides in the management section in the first place:
> > >
> > > simply
> > >
> > > > because I saw overrides as a management subject.
> > > >
> > > >
> > > >
> > > > About using the existing dependency tag to define replacements: I
> > > > tried
> > > > that (in a way, I still used a different tag name though). The issue
> > > > I
> > >
> > > have
> > >
> > > > with it is that the dependency tag can also take version, exclusions,
> > > > optional, etc. and I want that to be in the
> > > > /project/dependencyManagement/dependencies section. I'm applying the
> > > > separation of concerns principle here: overrides should simply map
> > >
> > > artifact
> > >
> > > > coordinates whereas managed dependencies are all about the right
> >
> > versions
> >
> > > > and such. Or maybe the managed dependencies should also provide the
> > > > override information? The entire existing implementation can still be
> > > > changed with little effort.
> > > >
> > > >
> > > >
> > > > I also thought about allowing 0..n overrides for one original, but I
> > > > decided to make it a 1:1 mapping. Let me explain: First, I think it
> > > > is
> > > > currently not possible to have lists in POMs without a wrapping
> >
> > element.
> >
> > > > One would have to write:
> > > >
> > > >
> > > >
> > > > <!-- Simplified code for brevity -->
> > > > <dependencyOverrides>
> > > >
> > > > <dependencyOverride>
> > > >
> > > > <original/>
> > > > <dependencies>
> > > >
> > > > <dependency/>
> > > > ...
> > > >
> > > > </dependencies>
> > > >
> > > > </dependencyOverride>
> > > >
> > > > </dependencyOverrides>
> > > >
> > > >
> > > >
> > > > Please correct me on this if I'm wrong. Second, I think most of the
> >
> > time
> >
> > > > people will be having 1:1 mappings anyway and with that in mind,
> > > > having
> > >
> > > the
> > >
> > > > need to use lists which require a wrapping element would bloat a POM.
> > > >
> > > >
> > > >
> > > > Long story short, your first point is up for discussion. If more
> > > > people
> > > > want overrides located elsewhere, then that's fine by me. Regarding
> >
> > your
> >
> > > > second point, I think the current approach is good and people would
> >
> > have
> >
> > > to
> > >
> > > > provide strong arguments to convince me of a different approach.
> > > >
> > > >
> > > >
> > > > Again, thanks for the feedback, it's really appreciated and if you
> > > > have
> > > > more, please let me know.
> > > >
> > > >
> > > >
> > > > Kind regards,
> > > > Enno
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Delany <de...@gmail.com>
> > > > Sent: Sunday, November 21, 2021 4:46 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > >
> > > >
> > > > Hi Enno,
> > > >
> > > >
> > > >
> > > > 2 things. I'd want to emphasise that the resolution of dependency
> > > > management info and the dependency overrides (more like a reactor
> > > > management concern) are independent of one another. Can achieve by
> > > > promoting the tag to project.
> > > >
> > > >
> > > >
> > > > Then why not use the existing dependency tag to define the
> > >
> > > replacement(s).
> > >
> > > > Accept 0, 1 or many.
> > > >
> > > >
> > > >
> > > > ...
> > > > <groupId>a</groupId>
> > > > <artifactId>a</artifactId>
> > > > <dependencyOverrides>
> > > >
> > > > <dependencyOverride>
> > > >
> > > > <original>
> > > >
> > > > <groupId>y</groupId>
> > > > <artifactId>y</artifactId>
> > > >
> > > > </original>
> > > > <dependency>
> > > >
> > > > <groupId>z</groupId>
> > > > <artifactId>z</artifactId>
> > > >
> > > > </dependency>
> > > > <dependency>
> > > >
> > > > <groupId>q</groupId>
> > > > <artifactId>q</artifactId>
> > > >
> > > > </dependency>
> > > >
> > > > </dependencyOverride>
> > > >
> > > > </dependencyOverrides>
> > > > <dependencies>
> > > >
> > > > <dependency>
> > > >
> > > > <groupId>w</groupId>
> > > > <artifactId>w</artifactId>
> > > >
> > > > </dependency>
> > > > <dependency>
> > > >
> > > > <groupId>x</groupId>
> > > > <artifactId>x</artifactId>
> > > >
> > > > </dependency>
> > > >
> > > > </dependencies>
> > > > ...
> > > >
> > > >
> > > >
> > > >
> > > > Regards,
> > > > Delany
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> >
> > Enno.Thieleke@holisticon.de
> >
> > > >
> > > >
> > > > wrote:
> > > >
> > > >
> > > >
> > > > > Hello,
> > > > >
> > > > >
> > > > >
> > > > > it's been a while and I've made some progress regarding
> > > > > overrides/replacements and wanted to share the current state.
> > > > >
> > > > >
> > > > >
> > > > > What's implemented/changed:
> > > > >
> > > > >
> > > > >
> > > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > >
> > > > > /project/dependencyManagement/dependencyOverrides which in turn can
> > >
> > > take
> > >
> > > > > the coordinates of original and overriding artifacts.
> > > > >
> > > > > * Overrides can be declared on any POM level in a hierarchy
> > > > > POMs
> > > >
> > > > (i.e.
> > > >
> > > > > parents and children.
> > > > >
> > > > > * Overrides can be imported from other POMs using the existing
> > > > >
> > > > > `import` scope for POMs in the dependencyManagement section.
> > > > >
> > > > > * If the same original artifact is overridden on different
> >
> > levels,
> >
> > > > the
> > > >
> > > > > "most downstream" wins.
> > > > >
> > > > > * An override *must* be accompanied by an entry in the
> > > > >
> > > > > dependencyManagement section. Maven generates an error and halts,
> > > > > if
> > > >
> > > > that's
> > > >
> > > > > not the case.
> > > > >
> > > > > * If an override is declared and consumed in the same effective
> > >
> > > POM,
> > >
> > > > > Maven generates a warning that the user should use the overriding
> > > >
> > > > artifact
> > > >
> > > > > instead of the original artifact.
> > > > >
> > > > > * The dependencies of an effective POM remain untouched.
> >
> > Overrides
> >
> > > > are
> > > >
> > > > > declared in POMs, but the act of overriding is implemented in
> > > > > maven-resolver.
> > > > >
> > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT,
> > > > > because
> > > > >
> > > > > interfaces needed additions. While some might consider this to be a
> > >
> > > minor
> > >
> > > > > change, I consider this to be a major change, because the
> > > > > interfaces
> > >
> > > are
> > >
> > > > > not (and cannot be, yet) sealed.
> > > > >
> > > > > * It is possible to override overrides of transitive
> >
> > dependencies.
> >
> > > In
> > >
> > > > > other words, it is possible to override overrides of POMs of
> > > >
> > > > dependencies.
> > > >
> > > > >
> > > > >
> > > > > While working on this I thought about names for
> >
> > overrides/replacements.
> >
> > > > > I'm still open to suggestions and pretty much undecided. Another
> > > > > name
> > > >
> > > > that
> > > >
> > > > > popped into my head is `dropinReplacements`, because it makes the
> > >
> > > intent
> > >
> > > > > very clear.
> > > > >
> > > > >
> > > > >
> > > > > For those of you who are interested, here are the links to the code
> > >
> > > again
> > >
> > > > > (so it's just one click away):
> > > > >
> > > > >
> > > > >
> > > > > *
> > > >
> > > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > >
> > > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > > >
> > > > >
> > > > >
> > > > > Also, I've rebased my changes onto master very recently.
> > > > >
> > > > >
> > > > >
> > > > > And here's the proposal itself:
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Over
> > rides.md
>
> > > > >
> > > > >
> > > > > If you find the time to look, please let me know what you think and
> > >
> > > what
> > >
> > > > > you think is missing.
> > > > >
> > > > >
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > >
> > > > >
> > > > > A few notes on the proposal:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > - Leave a dependency graph virtually untouched.
> > > > > Only change/override nodes in place. Don't exclude dependencies
> >
> > and
> >
> > > > > include new ones on a different level in the graph.
> > > > >
> > > > >
> > > > >
> > > > > Think, whatever it means, served dependencies in mojo shouldnt have
> >
> > to
> >
> > > > rely
> > > >
> > > > > on this new section using getXArtifact or dependency visitor. No
> > > > > real
> > > >
> > > > good
> > > >
> > > > > reason to break everyone there.
> > > > >
> > > > >
> > > > >
> > > > > A not used override must break the build (it is an unexpected bug
> > > > > and
> > > >
> > > > would
> > > >
> > > > > make the dev life hard otherwise). I perfectly see that it will
> > > > > break
> > > > > building a submodule in several cases but otherwise the section
> > > > > will
> > > >
> > > > become
> > > >
> > > > > unmanageable with time (see hibernate or cxf example) and since you
> > >
> > > loose
> > >
> > > > > the dependency relationship with this option compared to
> > > > > exclusions,
> >
> > it
> >
> > > > way
> > > >
> > > > > too much work to maintain it in practise. (This is why I think it
> > > >
> > > > shouldnt
> > > >
> > > > > be done this way but very worse case at dependency level giving
> > > > > hints
> > >
> > > for
> > >
> > > > > overrides and not elsewhere, mixed with dependency managementnit is
> > > >
> > > > trivial
> > > >
> > > > > to handle and maintain then).
> > > > >
> > > > >
> > > > >
> > > > > Pom rewriter must handle this section by dropping it and replacing
> > > > > it
> > >
> > > by
> > >
> > > > > exludes to keep compatibility with 3rd party resolvers
> > > > > (deployment).
> > > > >
> > > > >
> > > > >
> > > > > Overall, I still think it would be neat to see it as an extension
> > > > > for
> > > >
> > > > maven
> > > >
> > > > > 3.8.2 or 4 to be testable and validate design choices and actual
> >
> > usage
> >
> > > on
> > >
> > > > > real dependencies compared to current option.
> > > > >
> > > > >
> > > > >
> > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > >
> > > Enno.Thieleke@holisticon.de
> > >
> > > > >
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > >
> > > > >
> > > > > > Hello again,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I tried to create a proposal in/under
> > > > > >
> > > > > >
> > > >
> > > >
> >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> >
> > > > > ,
> > > > >
> > > > > > but I'm not allowed to, which makes sense since I'm new to the
> >
> > wiki,
> >
> > > > so I
> > > >
> > > > > > committed a proposal to my fork:
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Over
> > rides.md
>
> > > > > >
> > > > > >
> > > > > > The current version probably still contains errors and misses
> >
> > details
> >
> > > > but
> > > >
> > > > > > I imo they need to be worked out in a group effort.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Some feedback/comments would be appreciated.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Maybe you could create a proposal page in your wiki and grant me
> >
> > edit
> >
> > > > > > rights (user eth)?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > > >
> > > > > >
> > > > > >
> > > > > > Just a few more questions before I start.
> > > > > >
> > > > > >
> > > > > >
> > > > > > For the issue: Would reopening
> > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> >
> > you
> >
> > > > like
> > > >
> > > > > > to see a new one?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Where do I create the proposal?
> > > > > >
> > > > > >
> > > > > >
> > > > > > What should be created first, the issue or the proposal? I'm
> >
> > asking,
> >
> > > > > > because in the proposal we'd work out the details and after
> > > > > > that's
> > > >
> > > > done,
> > > >
> > > > > > that's where the issue becomes relevant (no issue, no code
> >
> > changes).
> >
> > > At
> > >
> > > > > > least that's how I'm used to implementing changes like this. I
> >
> > don't
> >
> > > > want
> > > >
> > > > > > to have created unnecessary noise in your issue system, if - for
> >
> > some
> >
> > > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > > > maven-resolver?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > > ________________________________
> > > > > > From: Michael Osipov <mi...@apache.org>
> > > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fw: Request for Enhancement: Dependency Overrides
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Enno,
Reusing import in another block with another semantic has too much
drawbacks for me:
1. it makes the meaning different depending where it is used
2. you need to create a kind of bom for overrides which is not really the
intent/will on user side (you literally want an exclude/include mecanism)
I still have issues with transitivity with this feature, both cases are
valid (using it or not) but if we enable it then we break easily projects
with > 1 import level so guess we don't have the choice to not use it which
means a consumed project with imports must rewrite the pom to promote
imports as excludes - exactly as you do to day without tat feature - to
keep modelVersion=4.0.0 and the artifact consumable so not sure the gain is
that huge since at the end and as mentionned you *already* have that
feature: create a packaging=pom module and use it instead of the direct
artifact you want to use if you care about repeating some dependency.
I perfectly understand the quickfix spirit in case of a CVE but at the end
we are already tooled for that (dependency plugin, oss index etc) so as a
developer you don't gain much and technically once you have
excluded/included the dep you want in a consumable pom you are iso having
imports in the parent so it is a one time work if properly setup so I kind
of still think we don't need to make the dev life more complex but maybe
document it and worse case enhance dependency plugin to do that for you:
mvn dependency:replace -Ddependency.replace.from=javax.foo -
Ddependency.replace.to=jakarta.foo. In other words this can be thought more
in terms of process than model feature which simplifies a lot the learning
curve, usage, integration and way of doing for end users.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 20 déc. 2021 à 21:26, Enno Thieleke <En...@holisticon.de> a
écrit :
> Hello again,
>
> judging by the increased traffic in this mailing list some of you seem to
> be on vacation. That's nice. I was hoping that this might be a good time to
> ask for your opinion again about what I wrote a couple of weeks ago?
>
> Kind regards
> Enno
>
> ________________________________
> From: Enno Thieleke <En...@holisticon.de>
> Sent: Friday, December 3, 2021 10:54 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi,
>
> concerning the request to change the override XML element to a
> fully-fledged dependency, thus removing the need for accompanying managed
> dependencies...
>
> tl;dr
> I would add a version attribute, nothing more, to the override XML
> element. The rest would remain unchanged.
>
> Full version:
>
> If I turned the override XML element into a fully-fledged dependency,
> should we support properties such as `scope` and `optional`? In my opinion
> we shouldn't, because that's still subject to original dependency
> definitions, not overrides. If people want to change the scope or add
> exclusions, they should stick to dependency management. That's what it's
> there for.
> I think it's enough to just add a version child-element to the current
> override XML element. That would remove the need for accompanying managed
> dependencies for just versions and in many simple cases that'd suffice,
> wouldn't you agree? I think we should draw the line here between changing
> artifact coordinates, a special kind of dependency management, and managing
> other dependency properties -> separation of concerns.
> Suppose I added a version child-element, I'd still have concerns about
> moving dependencyOverrides up one level so that it would be a sibling of
> dependencyManagement. Imagine I moved dependencyOverrides up one level. How
> would we import them properly? Currently importing a POM imports both:
> managed dependencies as well as overrides and I think that wouldn't be the
> right approach anymore. Would special import XML elements do the trick?
> Such as this:
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> ...
> <scope>import</scope> <!-- Imports managed dependencies -->
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencyOverrides>
> <imports>
> <import> <!-- Imports overrides; the packaging of the import MUST be
> pom -->
> <groupId/>
> <artifactId/>
> <version/>
> </import>
> </imports>
> ...
> </dependencyOverrides>
>
> To be honest: I think that'd suck. Another way would be to introduce a new
> special purpose scope, but I think the existing special purpose scope
> "import" is perfect: it's meant to import dependency management information
> from different POMs and since overrides affect dependencies in the sense
> that they manage dependency coordinates, we're still talking about
> dependency management.
>
> Please let me know what you think.
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Monday, November 22, 2021 2:33 PM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de>
> a
> écrit :
>
> > Hello,
> >
> > @Delany, regarding 1 and 2: If I added all the other elements of the
> > dependency tag, I would have to apply dependency management anyway if
> > present (and I played around with it for a bit), but I see your point.
> > Maybe using the dependency tag (I'd still name it override though) is
> "good
> > enough" for small projects/POMs. I will throw a bit of time at it and
> check
> > for "bad" implications.
> >
> > Making the override tag optional to have some sort of global exclusion
> > mechanism is out of scope. Let me explain: When dependency management
> comes
> > into play (in maven-resolver), it is not designed/intended to suddenly
> have
> > no dependency at hand to work with. The dependency node in the graph
> > already exists and the only thing that's left to do is filling it with
> the
> > right information. I would have to rewrite/change that code as well. I.e.
> > the code would have to check for a dependencyOverride with a matching
> > original with no override. To be honest, I personally find that to be
> > confusing. An exclusion should be explicit, because it carries a lot of
> > weight in my opinion. The absence of an XML element should not make for
> an
> > exclusion. Global excludes should exist though, just in a different way.
> >
> > @Romain, I disagree that not defining the version in an override could be
> > a source of big issues, because it would have to be defined in dependency
> > management anyway, so it's basically there. Changing the major version is
> > possible, even today, simply by using dependency management. It is the
> > responsibility of the developer to provide a proper override (which is
> why
> > I suggested a different name, dropinReplacement, to make the intent
> > clearer). Still, as stated earlier, I will see what I can do. No promises
> > though. :)
> >
>
> I never said I like that but it is what it is so "it would have to be
> defined in dependency management" is an assumption you cannot do and is
> erroneous and I don't see us saying you can't use this override feature
> and/or we break your project if you do so I guess we don't have much choice
> than baking it completely and not half.
>
> Keep in mind dependencyManagement does not behave as dependency override
> but that it solves similar issues (controlling your dependency graph for
> submodules since in a single module it is not that useful and excludes are
> more straight forwards) so as an user you will want to put it in the same
> (root? ;)) pom to keep the maintenance easy - spreading overrides in all
> poms is not easy to handle in time, this is why mgt block beats dependency
> for ex in multimodule projects, I don't see why it wouldn't be the same for
> overrides.
>
> Alternatively we can fail if we hit this case to prevent overrides in such
> a case, can be okish in first versions maybe?
>
>
> >
> > I agree, having 2 dependencies with the same coordinates but different
> > versions is a common thing. But in a single Maven module maven-resolver
> > would see to it that there's only one version on the classpath. After
> all,
> > we're not talking about OSGi (thank god). It's different for multiple
> Maven
> > modules though and you know it, so I won't elaborate.
> >
>
> Would mean you forbid overrides in packaging=pom modules, not sure it would
> be that useful to do so since you would duplicate the override in all
> modules.
> Makes a lot of noise compared to excludes in a depMgt block form my quick
> tests so guess it is not the intent ;).
>
>
> >
> > And yes, overriding the classifier (and extension/type) should be
> possible
> > too. And it already is, but it needs more testing, which I'm working on.
> >
>
> 👍
>
>
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Monday, November 22, 2021 11:00 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi all,
> >
> > I fear not defining the version is likely a source of big issues and
> worse
> > than not having this feature at all since often, when you change the
> major,
> > you change totally the dependency and the override will just not work.
> > You can indeed say you must not have 2 dependencies in different versions
> > but it is what it is and it is not that uncommon - in particular for libs
> > (and if you want to force a single version you use dependency
> management).
> > So if this feature is desired I fear it must include the version and
> likely
> > manage the classifier as well to work.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a
> écrit
> > :
> >
> > > Hi Enno,
> > >
> > > On point 1, figuring out the order of events in a build can be
> > challenging
> > > for newbies since Maven is declarative. For example profiles are
> resolved
> > > early on and this is reflected by their place in the pom. Although
> that's
> > > really about config composition, having the overrides under project
> could
> > > also hint at their special nature. No strong argument to make.
> > >
> > > Point 2, you say you are following a separation of concerns, but it
> seems
> > > rather you are forcing one. By requiring dependency management the
> result
> > > is a tight coupling between stages of resolving the final dependencies
> > (not
> > > being self-contained, you probably *should* make dependencyOverrides a
> > > child of dependencyManagement).
> > > Maven doesn't require managing dependencies, but your overrides do.
> > There's
> > > no harm in picking up config provided by DM, but why force the
> > > relationship? If someone wants to add an exclude at the time of an
> > > override, frankly that should just be "not your problem". Reusing an
> > > existing structure is surely preferable to inventing another one? Would
> > the
> > > enforcer rules have to learn about your new structure?
> > > I see why you went the path of only groupId:artifactId - you copied the
> > > exclusion structure. But then excluding doesn't require DM.
> > >
> > > You're right about wrapping the lists. Will you at least allow not
> > defining
> > > a dependency at all, aka a global exclude?
> > >
> > > Delany
> > >
> > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <
> Enno.Thieleke@holisticon.de
> > >
> > > wrote:
> > >
> > > > Hi, Delany,
> > > >
> > > > thanks for the feedback.
> > > >
> > > > I get your point that management and overrides can be seen as
> > > independent.
> > > > To be honest, I'm really not picky about where in the POM overrides
> > > should
> > > > be located. I was hoping for opinions on this from others (and was
> not
> > > > disappointed) and at least one strong opinion from the Maven core
> team.
> > > As
> > > > to why I put overrides in the management section in the first place:
> > > simply
> > > > because I saw overrides as a management subject.
> > > >
> > > > About using the existing dependency tag to define replacements: I
> tried
> > > > that (in a way, I still used a different tag name though). The issue
> I
> > > have
> > > > with it is that the dependency tag can also take version, exclusions,
> > > > optional, etc. and I want that to be in the
> > > > /project/dependencyManagement/dependencies section. I'm applying the
> > > > separation of concerns principle here: overrides should simply map
> > > artifact
> > > > coordinates whereas managed dependencies are all about the right
> > versions
> > > > and such. Or maybe the managed dependencies should also provide the
> > > > override information? The entire existing implementation can still be
> > > > changed with little effort.
> > > >
> > > > I also thought about allowing 0..n overrides for one original, but I
> > > > decided to make it a 1:1 mapping. Let me explain: First, I think it
> is
> > > > currently not possible to have lists in POMs without a wrapping
> > element.
> > > > One would have to write:
> > > >
> > > > <!-- Simplified code for brevity -->
> > > > <dependencyOverrides>
> > > > <dependencyOverride>
> > > > <original/>
> > > > <dependencies>
> > > > <dependency/>
> > > > ...
> > > > </dependencies>
> > > > </dependencyOverride>
> > > > </dependencyOverrides>
> > > >
> > > > Please correct me on this if I'm wrong. Second, I think most of the
> > time
> > > > people will be having 1:1 mappings anyway and with that in mind,
> having
> > > the
> > > > need to use lists which require a wrapping element would bloat a POM.
> > > >
> > > > Long story short, your first point is up for discussion. If more
> people
> > > > want overrides located elsewhere, then that's fine by me. Regarding
> > your
> > > > second point, I think the current approach is good and people would
> > have
> > > to
> > > > provide strong arguments to convince me of a different approach.
> > > >
> > > > Again, thanks for the feedback, it's really appreciated and if you
> have
> > > > more, please let me know.
> > > >
> > > > Kind regards,
> > > > Enno
> > > >
> > > > ________________________________
> > > > From: Delany <de...@gmail.com>
> > > > Sent: Sunday, November 21, 2021 4:46 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > > Hi Enno,
> > > >
> > > > 2 things. I'd want to emphasise that the resolution of dependency
> > > > management info and the dependency overrides (more like a reactor
> > > > management concern) are independent of one another. Can achieve by
> > > > promoting the tag to project.
> > > >
> > > > Then why not use the existing dependency tag to define the
> > > replacement(s).
> > > > Accept 0, 1 or many.
> > > >
> > > > ...
> > > > <groupId>a</groupId>
> > > > <artifactId>a</artifactId>
> > > > <dependencyOverrides>
> > > > <dependencyOverride>
> > > > <original>
> > > > <groupId>y</groupId>
> > > > <artifactId>y</artifactId>
> > > > </original>
> > > > <dependency>
> > > > <groupId>z</groupId>
> > > > <artifactId>z</artifactId>
> > > > </dependency>
> > > > <dependency>
> > > > <groupId>q</groupId>
> > > > <artifactId>q</artifactId>
> > > > </dependency>
> > > > </dependencyOverride>
> > > > </dependencyOverrides>
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>w</groupId>
> > > > <artifactId>w</artifactId>
> > > > </dependency>
> > > > <dependency>
> > > > <groupId>x</groupId>
> > > > <artifactId>x</artifactId>
> > > > </dependency>
> > > > </dependencies>
> > > > ...
> > > >
> > > >
> > > > Regards,
> > > > Delany
> > > >
> > > >
> > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> > Enno.Thieleke@holisticon.de
> > > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > it's been a while and I've made some progress regarding
> > > > > overrides/replacements and wanted to share the current state.
> > > > >
> > > > > What's implemented/changed:
> > > > >
> > > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > > /project/dependencyManagement/dependencyOverrides which in turn can
> > > take
> > > > > the coordinates of original and overriding artifacts.
> > > > > * Overrides can be declared on any POM level in a hierarchy
> POMs
> > > > (i.e.
> > > > > parents and children.
> > > > > * Overrides can be imported from other POMs using the existing
> > > > > `import` scope for POMs in the dependencyManagement section.
> > > > > * If the same original artifact is overridden on different
> > levels,
> > > > the
> > > > > "most downstream" wins.
> > > > > * An override *must* be accompanied by an entry in the
> > > > > dependencyManagement section. Maven generates an error and halts,
> if
> > > > that's
> > > > > not the case.
> > > > > * If an override is declared and consumed in the same effective
> > > POM,
> > > > > Maven generates a warning that the user should use the overriding
> > > > artifact
> > > > > instead of the original artifact.
> > > > > * The dependencies of an effective POM remain untouched.
> > Overrides
> > > > are
> > > > > declared in POMs, but the act of overriding is implemented in
> > > > > maven-resolver.
> > > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT,
> because
> > > > > interfaces needed additions. While some might consider this to be a
> > > minor
> > > > > change, I consider this to be a major change, because the
> interfaces
> > > are
> > > > > not (and cannot be, yet) sealed.
> > > > > * It is possible to override overrides of transitive
> > dependencies.
> > > In
> > > > > other words, it is possible to override overrides of POMs of
> > > > dependencies.
> > > > >
> > > > > While working on this I thought about names for
> > overrides/replacements.
> > > > > I'm still open to suggestions and pretty much undecided. Another
> name
> > > > that
> > > > > popped into my head is `dropinReplacements`, because it makes the
> > > intent
> > > > > very clear.
> > > > >
> > > > > For those of you who are interested, here are the links to the code
> > > again
> > > > > (so it's just one click away):
> > > > >
> > > > > *
> > > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > > *
> https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > > >
> > > > > Also, I've rebased my changes onto master very recently.
> > > > >
> > > > > And here's the proposal itself:
> > > > >
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > > >
> > > > > If you find the time to look, please let me know what you think and
> > > what
> > > > > you think is missing.
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > >
> > > > > ________________________________
> > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > > A few notes on the proposal:
> > > > >
> > > > >
> > > > > - Leave a dependency graph virtually untouched.
> > > > > Only change/override nodes in place. Don't exclude dependencies
> > and
> > > > > include new ones on a different level in the graph.
> > > > >
> > > > > Think, whatever it means, served dependencies in mojo shouldnt have
> > to
> > > > rely
> > > > > on this new section using getXArtifact or dependency visitor. No
> real
> > > > good
> > > > > reason to break everyone there.
> > > > >
> > > > > A not used override must break the build (it is an unexpected bug
> and
> > > > would
> > > > > make the dev life hard otherwise). I perfectly see that it will
> break
> > > > > building a submodule in several cases but otherwise the section
> will
> > > > become
> > > > > unmanageable with time (see hibernate or cxf example) and since you
> > > loose
> > > > > the dependency relationship with this option compared to
> exclusions,
> > it
> > > > way
> > > > > too much work to maintain it in practise. (This is why I think it
> > > > shouldnt
> > > > > be done this way but very worse case at dependency level giving
> hints
> > > for
> > > > > overrides and not elsewhere, mixed with dependency managementnit is
> > > > trivial
> > > > > to handle and maintain then).
> > > > >
> > > > > Pom rewriter must handle this section by dropping it and replacing
> it
> > > by
> > > > > exludes to keep compatibility with 3rd party resolvers
> (deployment).
> > > > >
> > > > > Overall, I still think it would be neat to see it as an extension
> for
> > > > maven
> > > > > 3.8.2 or 4 to be testable and validate design choices and actual
> > usage
> > > on
> > > > > real dependencies compared to current option.
> > > > >
> > > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > > Enno.Thieleke@holisticon.de
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > Hello again,
> > > > > >
> > > > > > I tried to create a proposal in/under
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > > > ,
> > > > > > but I'm not allowed to, which makes sense since I'm new to the
> > wiki,
> > > > so I
> > > > > > committed a proposal to my fork:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > > > >
> > > > > > The current version probably still contains errors and misses
> > details
> > > > but
> > > > > > I imo they need to be worked out in a group effort.
> > > > > >
> > > > > > Some feedback/comments would be appreciated.
> > > > > >
> > > > > > Maybe you could create a proposal page in your wiki and grant me
> > edit
> > > > > > rights (user eth)?
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > >
> > > > > > ________________________________
> > > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > > >
> > > > > > Just a few more questions before I start.
> > > > > >
> > > > > > For the issue: Would reopening
> > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> > you
> > > > like
> > > > > > to see a new one?
> > > > > >
> > > > > > Where do I create the proposal?
> > > > > >
> > > > > > What should be created first, the issue or the proposal? I'm
> > asking,
> > > > > > because in the proposal we'd work out the details and after
> that's
> > > > done,
> > > > > > that's where the issue becomes relevant (no issue, no code
> > changes).
> > > At
> > > > > > least that's how I'm used to implementing changes like this. I
> > don't
> > > > want
> > > > > > to have created unnecessary noise in your issue system, if - for
> > some
> > > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > > >
> > > > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > > > maven-resolver?
> > > > > >
> > > > > > Kind regards
> > > > > > Enno
> > > > > > ________________________________
> > > > > > From: Michael Osipov <mi...@apache.org>
> > > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Fw: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
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 <En...@holisticon.de>
Sent: Friday, December 3, 2021 10:54 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
Hi,
concerning the request to change the override XML element to a fully-fledged dependency, thus removing the need for accompanying managed dependencies...
tl;dr
I would add a version attribute, nothing more, to the override XML element. The rest would remain unchanged.
Full version:
If I turned the override XML element into a fully-fledged dependency, should we support properties such as `scope` and `optional`? In my opinion we shouldn't, because that's still subject to original dependency definitions, not overrides. If people want to change the scope or add exclusions, they should stick to dependency management. That's what it's there for.
I think it's enough to just add a version child-element to the current override XML element. That would remove the need for accompanying managed dependencies for just versions and in many simple cases that'd suffice, wouldn't you agree? I think we should draw the line here between changing artifact coordinates, a special kind of dependency management, and managing other dependency properties -> separation of concerns.
Suppose I added a version child-element, I'd still have concerns about moving dependencyOverrides up one level so that it would be a sibling of dependencyManagement. Imagine I moved dependencyOverrides up one level. How would we import them properly? Currently importing a POM imports both: managed dependencies as well as overrides and I think that wouldn't be the right approach anymore. Would special import XML elements do the trick? Such as this:
<dependencyManagement>
<dependencies>
<dependency>
...
<scope>import</scope> <!-- Imports managed dependencies -->
</dependency>
</dependencies>
</dependencyManagement>
<dependencyOverrides>
<imports>
<import> <!-- Imports overrides; the packaging of the import MUST be pom -->
<groupId/>
<artifactId/>
<version/>
</import>
</imports>
...
</dependencyOverrides>
To be honest: I think that'd suck. Another way would be to introduce a new special purpose scope, but I think the existing special purpose scope "import" is perfect: it's meant to import dependency management information from different POMs and since overrides affect dependencies in the sense that they manage dependency coordinates, we're still talking about dependency management.
Please let me know what you think.
Kind regards
Enno
________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Monday, November 22, 2021 2:33 PM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de> a
écrit :
> Hello,
>
> @Delany, regarding 1 and 2: If I added all the other elements of the
> dependency tag, I would have to apply dependency management anyway if
> present (and I played around with it for a bit), but I see your point.
> Maybe using the dependency tag (I'd still name it override though) is "good
> enough" for small projects/POMs. I will throw a bit of time at it and check
> for "bad" implications.
>
> Making the override tag optional to have some sort of global exclusion
> mechanism is out of scope. Let me explain: When dependency management comes
> into play (in maven-resolver), it is not designed/intended to suddenly have
> no dependency at hand to work with. The dependency node in the graph
> already exists and the only thing that's left to do is filling it with the
> right information. I would have to rewrite/change that code as well. I.e.
> the code would have to check for a dependencyOverride with a matching
> original with no override. To be honest, I personally find that to be
> confusing. An exclusion should be explicit, because it carries a lot of
> weight in my opinion. The absence of an XML element should not make for an
> exclusion. Global excludes should exist though, just in a different way.
>
> @Romain, I disagree that not defining the version in an override could be
> a source of big issues, because it would have to be defined in dependency
> management anyway, so it's basically there. Changing the major version is
> possible, even today, simply by using dependency management. It is the
> responsibility of the developer to provide a proper override (which is why
> I suggested a different name, dropinReplacement, to make the intent
> clearer). Still, as stated earlier, I will see what I can do. No promises
> though. :)
>
I never said I like that but it is what it is so "it would have to be
defined in dependency management" is an assumption you cannot do and is
erroneous and I don't see us saying you can't use this override feature
and/or we break your project if you do so I guess we don't have much choice
than baking it completely and not half.
Keep in mind dependencyManagement does not behave as dependency override
but that it solves similar issues (controlling your dependency graph for
submodules since in a single module it is not that useful and excludes are
more straight forwards) so as an user you will want to put it in the same
(root? ;)) pom to keep the maintenance easy - spreading overrides in all
poms is not easy to handle in time, this is why mgt block beats dependency
for ex in multimodule projects, I don't see why it wouldn't be the same for
overrides.
Alternatively we can fail if we hit this case to prevent overrides in such
a case, can be okish in first versions maybe?
>
> I agree, having 2 dependencies with the same coordinates but different
> versions is a common thing. But in a single Maven module maven-resolver
> would see to it that there's only one version on the classpath. After all,
> we're not talking about OSGi (thank god). It's different for multiple Maven
> modules though and you know it, so I won't elaborate.
>
Would mean you forbid overrides in packaging=pom modules, not sure it would
be that useful to do so since you would duplicate the override in all
modules.
Makes a lot of noise compared to excludes in a depMgt block form my quick
tests so guess it is not the intent ;).
>
> And yes, overriding the classifier (and extension/type) should be possible
> too. And it already is, but it needs more testing, which I'm working on.
>
👍
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Monday, November 22, 2021 11:00 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi all,
>
> I fear not defining the version is likely a source of big issues and worse
> than not having this feature at all since often, when you change the major,
> you change totally the dependency and the override will just not work.
> You can indeed say you must not have 2 dependencies in different versions
> but it is what it is and it is not that uncommon - in particular for libs
> (and if you want to force a single version you use dependency management).
> So if this feature is desired I fear it must include the version and likely
> manage the classifier as well to work.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a écrit
> :
>
> > Hi Enno,
> >
> > On point 1, figuring out the order of events in a build can be
> challenging
> > for newbies since Maven is declarative. For example profiles are resolved
> > early on and this is reflected by their place in the pom. Although that's
> > really about config composition, having the overrides under project could
> > also hint at their special nature. No strong argument to make.
> >
> > Point 2, you say you are following a separation of concerns, but it seems
> > rather you are forcing one. By requiring dependency management the result
> > is a tight coupling between stages of resolving the final dependencies
> (not
> > being self-contained, you probably *should* make dependencyOverrides a
> > child of dependencyManagement).
> > Maven doesn't require managing dependencies, but your overrides do.
> There's
> > no harm in picking up config provided by DM, but why force the
> > relationship? If someone wants to add an exclude at the time of an
> > override, frankly that should just be "not your problem". Reusing an
> > existing structure is surely preferable to inventing another one? Would
> the
> > enforcer rules have to learn about your new structure?
> > I see why you went the path of only groupId:artifactId - you copied the
> > exclusion structure. But then excluding doesn't require DM.
> >
> > You're right about wrapping the lists. Will you at least allow not
> defining
> > a dependency at all, aka a global exclude?
> >
> > Delany
> >
> > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <Enno.Thieleke@holisticon.de
> >
> > wrote:
> >
> > > Hi, Delany,
> > >
> > > thanks for the feedback.
> > >
> > > I get your point that management and overrides can be seen as
> > independent.
> > > To be honest, I'm really not picky about where in the POM overrides
> > should
> > > be located. I was hoping for opinions on this from others (and was not
> > > disappointed) and at least one strong opinion from the Maven core team.
> > As
> > > to why I put overrides in the management section in the first place:
> > simply
> > > because I saw overrides as a management subject.
> > >
> > > About using the existing dependency tag to define replacements: I tried
> > > that (in a way, I still used a different tag name though). The issue I
> > have
> > > with it is that the dependency tag can also take version, exclusions,
> > > optional, etc. and I want that to be in the
> > > /project/dependencyManagement/dependencies section. I'm applying the
> > > separation of concerns principle here: overrides should simply map
> > artifact
> > > coordinates whereas managed dependencies are all about the right
> versions
> > > and such. Or maybe the managed dependencies should also provide the
> > > override information? The entire existing implementation can still be
> > > changed with little effort.
> > >
> > > I also thought about allowing 0..n overrides for one original, but I
> > > decided to make it a 1:1 mapping. Let me explain: First, I think it is
> > > currently not possible to have lists in POMs without a wrapping
> element.
> > > One would have to write:
> > >
> > > <!-- Simplified code for brevity -->
> > > <dependencyOverrides>
> > > <dependencyOverride>
> > > <original/>
> > > <dependencies>
> > > <dependency/>
> > > ...
> > > </dependencies>
> > > </dependencyOverride>
> > > </dependencyOverrides>
> > >
> > > Please correct me on this if I'm wrong. Second, I think most of the
> time
> > > people will be having 1:1 mappings anyway and with that in mind, having
> > the
> > > need to use lists which require a wrapping element would bloat a POM.
> > >
> > > Long story short, your first point is up for discussion. If more people
> > > want overrides located elsewhere, then that's fine by me. Regarding
> your
> > > second point, I think the current approach is good and people would
> have
> > to
> > > provide strong arguments to convince me of a different approach.
> > >
> > > Again, thanks for the feedback, it's really appreciated and if you have
> > > more, please let me know.
> > >
> > > Kind regards,
> > > Enno
> > >
> > > ________________________________
> > > From: Delany <de...@gmail.com>
> > > Sent: Sunday, November 21, 2021 4:46 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > Hi Enno,
> > >
> > > 2 things. I'd want to emphasise that the resolution of dependency
> > > management info and the dependency overrides (more like a reactor
> > > management concern) are independent of one another. Can achieve by
> > > promoting the tag to project.
> > >
> > > Then why not use the existing dependency tag to define the
> > replacement(s).
> > > Accept 0, 1 or many.
> > >
> > > ...
> > > <groupId>a</groupId>
> > > <artifactId>a</artifactId>
> > > <dependencyOverrides>
> > > <dependencyOverride>
> > > <original>
> > > <groupId>y</groupId>
> > > <artifactId>y</artifactId>
> > > </original>
> > > <dependency>
> > > <groupId>z</groupId>
> > > <artifactId>z</artifactId>
> > > </dependency>
> > > <dependency>
> > > <groupId>q</groupId>
> > > <artifactId>q</artifactId>
> > > </dependency>
> > > </dependencyOverride>
> > > </dependencyOverrides>
> > > <dependencies>
> > > <dependency>
> > > <groupId>w</groupId>
> > > <artifactId>w</artifactId>
> > > </dependency>
> > > <dependency>
> > > <groupId>x</groupId>
> > > <artifactId>x</artifactId>
> > > </dependency>
> > > </dependencies>
> > > ...
> > >
> > >
> > > Regards,
> > > Delany
> > >
> > >
> > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> Enno.Thieleke@holisticon.de
> > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > it's been a while and I've made some progress regarding
> > > > overrides/replacements and wanted to share the current state.
> > > >
> > > > What's implemented/changed:
> > > >
> > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > /project/dependencyManagement/dependencyOverrides which in turn can
> > take
> > > > the coordinates of original and overriding artifacts.
> > > > * Overrides can be declared on any POM level in a hierarchy POMs
> > > (i.e.
> > > > parents and children.
> > > > * Overrides can be imported from other POMs using the existing
> > > > `import` scope for POMs in the dependencyManagement section.
> > > > * If the same original artifact is overridden on different
> levels,
> > > the
> > > > "most downstream" wins.
> > > > * An override *must* be accompanied by an entry in the
> > > > dependencyManagement section. Maven generates an error and halts, if
> > > that's
> > > > not the case.
> > > > * If an override is declared and consumed in the same effective
> > POM,
> > > > Maven generates a warning that the user should use the overriding
> > > artifact
> > > > instead of the original artifact.
> > > > * The dependencies of an effective POM remain untouched.
> Overrides
> > > are
> > > > declared in POMs, but the act of overriding is implemented in
> > > > maven-resolver.
> > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> > > > interfaces needed additions. While some might consider this to be a
> > minor
> > > > change, I consider this to be a major change, because the interfaces
> > are
> > > > not (and cannot be, yet) sealed.
> > > > * It is possible to override overrides of transitive
> dependencies.
> > In
> > > > other words, it is possible to override overrides of POMs of
> > > dependencies.
> > > >
> > > > While working on this I thought about names for
> overrides/replacements.
> > > > I'm still open to suggestions and pretty much undecided. Another name
> > > that
> > > > popped into my head is `dropinReplacements`, because it makes the
> > intent
> > > > very clear.
> > > >
> > > > For those of you who are interested, here are the links to the code
> > again
> > > > (so it's just one click away):
> > > >
> > > > *
> > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > >
> > > > Also, I've rebased my changes onto master very recently.
> > > >
> > > > And here's the proposal itself:
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > >
> > > > If you find the time to look, please let me know what you think and
> > what
> > > > you think is missing.
> > > >
> > > > Kind regards
> > > > Enno
> > > >
> > > > ________________________________
> > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > > A few notes on the proposal:
> > > >
> > > >
> > > > - Leave a dependency graph virtually untouched.
> > > > Only change/override nodes in place. Don't exclude dependencies
> and
> > > > include new ones on a different level in the graph.
> > > >
> > > > Think, whatever it means, served dependencies in mojo shouldnt have
> to
> > > rely
> > > > on this new section using getXArtifact or dependency visitor. No real
> > > good
> > > > reason to break everyone there.
> > > >
> > > > A not used override must break the build (it is an unexpected bug and
> > > would
> > > > make the dev life hard otherwise). I perfectly see that it will break
> > > > building a submodule in several cases but otherwise the section will
> > > become
> > > > unmanageable with time (see hibernate or cxf example) and since you
> > loose
> > > > the dependency relationship with this option compared to exclusions,
> it
> > > way
> > > > too much work to maintain it in practise. (This is why I think it
> > > shouldnt
> > > > be done this way but very worse case at dependency level giving hints
> > for
> > > > overrides and not elsewhere, mixed with dependency managementnit is
> > > trivial
> > > > to handle and maintain then).
> > > >
> > > > Pom rewriter must handle this section by dropping it and replacing it
> > by
> > > > exludes to keep compatibility with 3rd party resolvers (deployment).
> > > >
> > > > Overall, I still think it would be neat to see it as an extension for
> > > maven
> > > > 3.8.2 or 4 to be testable and validate design choices and actual
> usage
> > on
> > > > real dependencies compared to current option.
> > > >
> > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > Enno.Thieleke@holisticon.de
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > Hello again,
> > > > >
> > > > > I tried to create a proposal in/under
> > > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > > ,
> > > > > but I'm not allowed to, which makes sense since I'm new to the
> wiki,
> > > so I
> > > > > committed a proposal to my fork:
> > > > >
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > > >
> > > > > The current version probably still contains errors and misses
> details
> > > but
> > > > > I imo they need to be worked out in a group effort.
> > > > >
> > > > > Some feedback/comments would be appreciated.
> > > > >
> > > > > Maybe you could create a proposal page in your wiki and grant me
> edit
> > > > > rights (user eth)?
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > >
> > > > > ________________________________
> > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > > Hi Michael,
> > > > >
> > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > >
> > > > > Just a few more questions before I start.
> > > > >
> > > > > For the issue: Would reopening
> > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> you
> > > like
> > > > > to see a new one?
> > > > >
> > > > > Where do I create the proposal?
> > > > >
> > > > > What should be created first, the issue or the proposal? I'm
> asking,
> > > > > because in the proposal we'd work out the details and after that's
> > > done,
> > > > > that's where the issue becomes relevant (no issue, no code
> changes).
> > At
> > > > > least that's how I'm used to implementing changes like this. I
> don't
> > > want
> > > > > to have created unnecessary noise in your issue system, if - for
> some
> > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > >
> > > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > > maven-resolver?
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > > ________________________________
> > > > > From: Michael Osipov <mi...@apache.org>
> > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
Hi,
concerning the request to change the override XML element to a fully-fledged dependency, thus removing the need for accompanying managed dependencies...
tl;dr
I would add a version attribute, nothing more, to the override XML element. The rest would remain unchanged.
Full version:
If I turned the override XML element into a fully-fledged dependency, should we support properties such as `scope` and `optional`? In my opinion we shouldn't, because that's still subject to original dependency definitions, not overrides. If people want to change the scope or add exclusions, they should stick to dependency management. That's what it's there for.
I think it's enough to just add a version child-element to the current override XML element. That would remove the need for accompanying managed dependencies for just versions and in many simple cases that'd suffice, wouldn't you agree? I think we should draw the line here between changing artifact coordinates, a special kind of dependency management, and managing other dependency properties -> separation of concerns.
Suppose I added a version child-element, I'd still have concerns about moving dependencyOverrides up one level so that it would be a sibling of dependencyManagement. Imagine I moved dependencyOverrides up one level. How would we import them properly? Currently importing a POM imports both: managed dependencies as well as overrides and I think that wouldn't be the right approach anymore. Would special import XML elements do the trick? Such as this:
<dependencyManagement>
<dependencies>
<dependency>
...
<scope>import</scope> <!-- Imports managed dependencies -->
</dependency>
</dependencies>
</dependencyManagement>
<dependencyOverrides>
<imports>
<import> <!-- Imports overrides; the packaging of the import MUST be pom -->
<groupId/>
<artifactId/>
<version/>
</import>
</imports>
...
</dependencyOverrides>
To be honest: I think that'd suck. Another way would be to introduce a new special purpose scope, but I think the existing special purpose scope "import" is perfect: it's meant to import dependency management information from different POMs and since overrides affect dependencies in the sense that they manage dependency coordinates, we're still talking about dependency management.
Please let me know what you think.
Kind regards
Enno
________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Monday, November 22, 2021 2:33 PM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de> a
écrit :
> Hello,
>
> @Delany, regarding 1 and 2: If I added all the other elements of the
> dependency tag, I would have to apply dependency management anyway if
> present (and I played around with it for a bit), but I see your point.
> Maybe using the dependency tag (I'd still name it override though) is "good
> enough" for small projects/POMs. I will throw a bit of time at it and check
> for "bad" implications.
>
> Making the override tag optional to have some sort of global exclusion
> mechanism is out of scope. Let me explain: When dependency management comes
> into play (in maven-resolver), it is not designed/intended to suddenly have
> no dependency at hand to work with. The dependency node in the graph
> already exists and the only thing that's left to do is filling it with the
> right information. I would have to rewrite/change that code as well. I.e.
> the code would have to check for a dependencyOverride with a matching
> original with no override. To be honest, I personally find that to be
> confusing. An exclusion should be explicit, because it carries a lot of
> weight in my opinion. The absence of an XML element should not make for an
> exclusion. Global excludes should exist though, just in a different way.
>
> @Romain, I disagree that not defining the version in an override could be
> a source of big issues, because it would have to be defined in dependency
> management anyway, so it's basically there. Changing the major version is
> possible, even today, simply by using dependency management. It is the
> responsibility of the developer to provide a proper override (which is why
> I suggested a different name, dropinReplacement, to make the intent
> clearer). Still, as stated earlier, I will see what I can do. No promises
> though. :)
>
I never said I like that but it is what it is so "it would have to be
defined in dependency management" is an assumption you cannot do and is
erroneous and I don't see us saying you can't use this override feature
and/or we break your project if you do so I guess we don't have much choice
than baking it completely and not half.
Keep in mind dependencyManagement does not behave as dependency override
but that it solves similar issues (controlling your dependency graph for
submodules since in a single module it is not that useful and excludes are
more straight forwards) so as an user you will want to put it in the same
(root? ;)) pom to keep the maintenance easy - spreading overrides in all
poms is not easy to handle in time, this is why mgt block beats dependency
for ex in multimodule projects, I don't see why it wouldn't be the same for
overrides.
Alternatively we can fail if we hit this case to prevent overrides in such
a case, can be okish in first versions maybe?
>
> I agree, having 2 dependencies with the same coordinates but different
> versions is a common thing. But in a single Maven module maven-resolver
> would see to it that there's only one version on the classpath. After all,
> we're not talking about OSGi (thank god). It's different for multiple Maven
> modules though and you know it, so I won't elaborate.
>
Would mean you forbid overrides in packaging=pom modules, not sure it would
be that useful to do so since you would duplicate the override in all
modules.
Makes a lot of noise compared to excludes in a depMgt block form my quick
tests so guess it is not the intent ;).
>
> And yes, overriding the classifier (and extension/type) should be possible
> too. And it already is, but it needs more testing, which I'm working on.
>
👍
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Monday, November 22, 2021 11:00 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi all,
>
> I fear not defining the version is likely a source of big issues and worse
> than not having this feature at all since often, when you change the major,
> you change totally the dependency and the override will just not work.
> You can indeed say you must not have 2 dependencies in different versions
> but it is what it is and it is not that uncommon - in particular for libs
> (and if you want to force a single version you use dependency management).
> So if this feature is desired I fear it must include the version and likely
> manage the classifier as well to work.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a écrit
> :
>
> > Hi Enno,
> >
> > On point 1, figuring out the order of events in a build can be
> challenging
> > for newbies since Maven is declarative. For example profiles are resolved
> > early on and this is reflected by their place in the pom. Although that's
> > really about config composition, having the overrides under project could
> > also hint at their special nature. No strong argument to make.
> >
> > Point 2, you say you are following a separation of concerns, but it seems
> > rather you are forcing one. By requiring dependency management the result
> > is a tight coupling between stages of resolving the final dependencies
> (not
> > being self-contained, you probably *should* make dependencyOverrides a
> > child of dependencyManagement).
> > Maven doesn't require managing dependencies, but your overrides do.
> There's
> > no harm in picking up config provided by DM, but why force the
> > relationship? If someone wants to add an exclude at the time of an
> > override, frankly that should just be "not your problem". Reusing an
> > existing structure is surely preferable to inventing another one? Would
> the
> > enforcer rules have to learn about your new structure?
> > I see why you went the path of only groupId:artifactId - you copied the
> > exclusion structure. But then excluding doesn't require DM.
> >
> > You're right about wrapping the lists. Will you at least allow not
> defining
> > a dependency at all, aka a global exclude?
> >
> > Delany
> >
> > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <Enno.Thieleke@holisticon.de
> >
> > wrote:
> >
> > > Hi, Delany,
> > >
> > > thanks for the feedback.
> > >
> > > I get your point that management and overrides can be seen as
> > independent.
> > > To be honest, I'm really not picky about where in the POM overrides
> > should
> > > be located. I was hoping for opinions on this from others (and was not
> > > disappointed) and at least one strong opinion from the Maven core team.
> > As
> > > to why I put overrides in the management section in the first place:
> > simply
> > > because I saw overrides as a management subject.
> > >
> > > About using the existing dependency tag to define replacements: I tried
> > > that (in a way, I still used a different tag name though). The issue I
> > have
> > > with it is that the dependency tag can also take version, exclusions,
> > > optional, etc. and I want that to be in the
> > > /project/dependencyManagement/dependencies section. I'm applying the
> > > separation of concerns principle here: overrides should simply map
> > artifact
> > > coordinates whereas managed dependencies are all about the right
> versions
> > > and such. Or maybe the managed dependencies should also provide the
> > > override information? The entire existing implementation can still be
> > > changed with little effort.
> > >
> > > I also thought about allowing 0..n overrides for one original, but I
> > > decided to make it a 1:1 mapping. Let me explain: First, I think it is
> > > currently not possible to have lists in POMs without a wrapping
> element.
> > > One would have to write:
> > >
> > > <!-- Simplified code for brevity -->
> > > <dependencyOverrides>
> > > <dependencyOverride>
> > > <original/>
> > > <dependencies>
> > > <dependency/>
> > > ...
> > > </dependencies>
> > > </dependencyOverride>
> > > </dependencyOverrides>
> > >
> > > Please correct me on this if I'm wrong. Second, I think most of the
> time
> > > people will be having 1:1 mappings anyway and with that in mind, having
> > the
> > > need to use lists which require a wrapping element would bloat a POM.
> > >
> > > Long story short, your first point is up for discussion. If more people
> > > want overrides located elsewhere, then that's fine by me. Regarding
> your
> > > second point, I think the current approach is good and people would
> have
> > to
> > > provide strong arguments to convince me of a different approach.
> > >
> > > Again, thanks for the feedback, it's really appreciated and if you have
> > > more, please let me know.
> > >
> > > Kind regards,
> > > Enno
> > >
> > > ________________________________
> > > From: Delany <de...@gmail.com>
> > > Sent: Sunday, November 21, 2021 4:46 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > Hi Enno,
> > >
> > > 2 things. I'd want to emphasise that the resolution of dependency
> > > management info and the dependency overrides (more like a reactor
> > > management concern) are independent of one another. Can achieve by
> > > promoting the tag to project.
> > >
> > > Then why not use the existing dependency tag to define the
> > replacement(s).
> > > Accept 0, 1 or many.
> > >
> > > ...
> > > <groupId>a</groupId>
> > > <artifactId>a</artifactId>
> > > <dependencyOverrides>
> > > <dependencyOverride>
> > > <original>
> > > <groupId>y</groupId>
> > > <artifactId>y</artifactId>
> > > </original>
> > > <dependency>
> > > <groupId>z</groupId>
> > > <artifactId>z</artifactId>
> > > </dependency>
> > > <dependency>
> > > <groupId>q</groupId>
> > > <artifactId>q</artifactId>
> > > </dependency>
> > > </dependencyOverride>
> > > </dependencyOverrides>
> > > <dependencies>
> > > <dependency>
> > > <groupId>w</groupId>
> > > <artifactId>w</artifactId>
> > > </dependency>
> > > <dependency>
> > > <groupId>x</groupId>
> > > <artifactId>x</artifactId>
> > > </dependency>
> > > </dependencies>
> > > ...
> > >
> > >
> > > Regards,
> > > Delany
> > >
> > >
> > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> Enno.Thieleke@holisticon.de
> > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > it's been a while and I've made some progress regarding
> > > > overrides/replacements and wanted to share the current state.
> > > >
> > > > What's implemented/changed:
> > > >
> > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > /project/dependencyManagement/dependencyOverrides which in turn can
> > take
> > > > the coordinates of original and overriding artifacts.
> > > > * Overrides can be declared on any POM level in a hierarchy POMs
> > > (i.e.
> > > > parents and children.
> > > > * Overrides can be imported from other POMs using the existing
> > > > `import` scope for POMs in the dependencyManagement section.
> > > > * If the same original artifact is overridden on different
> levels,
> > > the
> > > > "most downstream" wins.
> > > > * An override *must* be accompanied by an entry in the
> > > > dependencyManagement section. Maven generates an error and halts, if
> > > that's
> > > > not the case.
> > > > * If an override is declared and consumed in the same effective
> > POM,
> > > > Maven generates a warning that the user should use the overriding
> > > artifact
> > > > instead of the original artifact.
> > > > * The dependencies of an effective POM remain untouched.
> Overrides
> > > are
> > > > declared in POMs, but the act of overriding is implemented in
> > > > maven-resolver.
> > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> > > > interfaces needed additions. While some might consider this to be a
> > minor
> > > > change, I consider this to be a major change, because the interfaces
> > are
> > > > not (and cannot be, yet) sealed.
> > > > * It is possible to override overrides of transitive
> dependencies.
> > In
> > > > other words, it is possible to override overrides of POMs of
> > > dependencies.
> > > >
> > > > While working on this I thought about names for
> overrides/replacements.
> > > > I'm still open to suggestions and pretty much undecided. Another name
> > > that
> > > > popped into my head is `dropinReplacements`, because it makes the
> > intent
> > > > very clear.
> > > >
> > > > For those of you who are interested, here are the links to the code
> > again
> > > > (so it's just one click away):
> > > >
> > > > *
> > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > >
> > > > Also, I've rebased my changes onto master very recently.
> > > >
> > > > And here's the proposal itself:
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > >
> > > > If you find the time to look, please let me know what you think and
> > what
> > > > you think is missing.
> > > >
> > > > Kind regards
> > > > Enno
> > > >
> > > > ________________________________
> > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > > A few notes on the proposal:
> > > >
> > > >
> > > > - Leave a dependency graph virtually untouched.
> > > > Only change/override nodes in place. Don't exclude dependencies
> and
> > > > include new ones on a different level in the graph.
> > > >
> > > > Think, whatever it means, served dependencies in mojo shouldnt have
> to
> > > rely
> > > > on this new section using getXArtifact or dependency visitor. No real
> > > good
> > > > reason to break everyone there.
> > > >
> > > > A not used override must break the build (it is an unexpected bug and
> > > would
> > > > make the dev life hard otherwise). I perfectly see that it will break
> > > > building a submodule in several cases but otherwise the section will
> > > become
> > > > unmanageable with time (see hibernate or cxf example) and since you
> > loose
> > > > the dependency relationship with this option compared to exclusions,
> it
> > > way
> > > > too much work to maintain it in practise. (This is why I think it
> > > shouldnt
> > > > be done this way but very worse case at dependency level giving hints
> > for
> > > > overrides and not elsewhere, mixed with dependency managementnit is
> > > trivial
> > > > to handle and maintain then).
> > > >
> > > > Pom rewriter must handle this section by dropping it and replacing it
> > by
> > > > exludes to keep compatibility with 3rd party resolvers (deployment).
> > > >
> > > > Overall, I still think it would be neat to see it as an extension for
> > > maven
> > > > 3.8.2 or 4 to be testable and validate design choices and actual
> usage
> > on
> > > > real dependencies compared to current option.
> > > >
> > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > Enno.Thieleke@holisticon.de
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > Hello again,
> > > > >
> > > > > I tried to create a proposal in/under
> > > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > > ,
> > > > > but I'm not allowed to, which makes sense since I'm new to the
> wiki,
> > > so I
> > > > > committed a proposal to my fork:
> > > > >
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > > >
> > > > > The current version probably still contains errors and misses
> details
> > > but
> > > > > I imo they need to be worked out in a group effort.
> > > > >
> > > > > Some feedback/comments would be appreciated.
> > > > >
> > > > > Maybe you could create a proposal page in your wiki and grant me
> edit
> > > > > rights (user eth)?
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > >
> > > > > ________________________________
> > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > > Hi Michael,
> > > > >
> > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > >
> > > > > Just a few more questions before I start.
> > > > >
> > > > > For the issue: Would reopening
> > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> you
> > > like
> > > > > to see a new one?
> > > > >
> > > > > Where do I create the proposal?
> > > > >
> > > > > What should be created first, the issue or the proposal? I'm
> asking,
> > > > > because in the proposal we'd work out the details and after that's
> > > done,
> > > > > that's where the issue becomes relevant (no issue, no code
> changes).
> > At
> > > > > least that's how I'm used to implementing changes like this. I
> don't
> > > want
> > > > > to have created unnecessary noise in your issue system, if - for
> some
> > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > >
> > > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > > maven-resolver?
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > > ________________________________
> > > > > From: Michael Osipov <mi...@apache.org>
> > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <En...@holisticon.de> a
écrit :
> Hello,
>
> @Delany, regarding 1 and 2: If I added all the other elements of the
> dependency tag, I would have to apply dependency management anyway if
> present (and I played around with it for a bit), but I see your point.
> Maybe using the dependency tag (I'd still name it override though) is "good
> enough" for small projects/POMs. I will throw a bit of time at it and check
> for "bad" implications.
>
> Making the override tag optional to have some sort of global exclusion
> mechanism is out of scope. Let me explain: When dependency management comes
> into play (in maven-resolver), it is not designed/intended to suddenly have
> no dependency at hand to work with. The dependency node in the graph
> already exists and the only thing that's left to do is filling it with the
> right information. I would have to rewrite/change that code as well. I.e.
> the code would have to check for a dependencyOverride with a matching
> original with no override. To be honest, I personally find that to be
> confusing. An exclusion should be explicit, because it carries a lot of
> weight in my opinion. The absence of an XML element should not make for an
> exclusion. Global excludes should exist though, just in a different way.
>
> @Romain, I disagree that not defining the version in an override could be
> a source of big issues, because it would have to be defined in dependency
> management anyway, so it's basically there. Changing the major version is
> possible, even today, simply by using dependency management. It is the
> responsibility of the developer to provide a proper override (which is why
> I suggested a different name, dropinReplacement, to make the intent
> clearer). Still, as stated earlier, I will see what I can do. No promises
> though. :)
>
I never said I like that but it is what it is so "it would have to be
defined in dependency management" is an assumption you cannot do and is
erroneous and I don't see us saying you can't use this override feature
and/or we break your project if you do so I guess we don't have much choice
than baking it completely and not half.
Keep in mind dependencyManagement does not behave as dependency override
but that it solves similar issues (controlling your dependency graph for
submodules since in a single module it is not that useful and excludes are
more straight forwards) so as an user you will want to put it in the same
(root? ;)) pom to keep the maintenance easy - spreading overrides in all
poms is not easy to handle in time, this is why mgt block beats dependency
for ex in multimodule projects, I don't see why it wouldn't be the same for
overrides.
Alternatively we can fail if we hit this case to prevent overrides in such
a case, can be okish in first versions maybe?
>
> I agree, having 2 dependencies with the same coordinates but different
> versions is a common thing. But in a single Maven module maven-resolver
> would see to it that there's only one version on the classpath. After all,
> we're not talking about OSGi (thank god). It's different for multiple Maven
> modules though and you know it, so I won't elaborate.
>
Would mean you forbid overrides in packaging=pom modules, not sure it would
be that useful to do so since you would duplicate the override in all
modules.
Makes a lot of noise compared to excludes in a depMgt block form my quick
tests so guess it is not the intent ;).
>
> And yes, overriding the classifier (and extension/type) should be possible
> too. And it already is, but it needs more testing, which I'm working on.
>
👍
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Monday, November 22, 2021 11:00 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi all,
>
> I fear not defining the version is likely a source of big issues and worse
> than not having this feature at all since often, when you change the major,
> you change totally the dependency and the override will just not work.
> You can indeed say you must not have 2 dependencies in different versions
> but it is what it is and it is not that uncommon - in particular for libs
> (and if you want to force a single version you use dependency management).
> So if this feature is desired I fear it must include the version and likely
> manage the classifier as well to work.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a écrit
> :
>
> > Hi Enno,
> >
> > On point 1, figuring out the order of events in a build can be
> challenging
> > for newbies since Maven is declarative. For example profiles are resolved
> > early on and this is reflected by their place in the pom. Although that's
> > really about config composition, having the overrides under project could
> > also hint at their special nature. No strong argument to make.
> >
> > Point 2, you say you are following a separation of concerns, but it seems
> > rather you are forcing one. By requiring dependency management the result
> > is a tight coupling between stages of resolving the final dependencies
> (not
> > being self-contained, you probably *should* make dependencyOverrides a
> > child of dependencyManagement).
> > Maven doesn't require managing dependencies, but your overrides do.
> There's
> > no harm in picking up config provided by DM, but why force the
> > relationship? If someone wants to add an exclude at the time of an
> > override, frankly that should just be "not your problem". Reusing an
> > existing structure is surely preferable to inventing another one? Would
> the
> > enforcer rules have to learn about your new structure?
> > I see why you went the path of only groupId:artifactId - you copied the
> > exclusion structure. But then excluding doesn't require DM.
> >
> > You're right about wrapping the lists. Will you at least allow not
> defining
> > a dependency at all, aka a global exclude?
> >
> > Delany
> >
> > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <Enno.Thieleke@holisticon.de
> >
> > wrote:
> >
> > > Hi, Delany,
> > >
> > > thanks for the feedback.
> > >
> > > I get your point that management and overrides can be seen as
> > independent.
> > > To be honest, I'm really not picky about where in the POM overrides
> > should
> > > be located. I was hoping for opinions on this from others (and was not
> > > disappointed) and at least one strong opinion from the Maven core team.
> > As
> > > to why I put overrides in the management section in the first place:
> > simply
> > > because I saw overrides as a management subject.
> > >
> > > About using the existing dependency tag to define replacements: I tried
> > > that (in a way, I still used a different tag name though). The issue I
> > have
> > > with it is that the dependency tag can also take version, exclusions,
> > > optional, etc. and I want that to be in the
> > > /project/dependencyManagement/dependencies section. I'm applying the
> > > separation of concerns principle here: overrides should simply map
> > artifact
> > > coordinates whereas managed dependencies are all about the right
> versions
> > > and such. Or maybe the managed dependencies should also provide the
> > > override information? The entire existing implementation can still be
> > > changed with little effort.
> > >
> > > I also thought about allowing 0..n overrides for one original, but I
> > > decided to make it a 1:1 mapping. Let me explain: First, I think it is
> > > currently not possible to have lists in POMs without a wrapping
> element.
> > > One would have to write:
> > >
> > > <!-- Simplified code for brevity -->
> > > <dependencyOverrides>
> > > <dependencyOverride>
> > > <original/>
> > > <dependencies>
> > > <dependency/>
> > > ...
> > > </dependencies>
> > > </dependencyOverride>
> > > </dependencyOverrides>
> > >
> > > Please correct me on this if I'm wrong. Second, I think most of the
> time
> > > people will be having 1:1 mappings anyway and with that in mind, having
> > the
> > > need to use lists which require a wrapping element would bloat a POM.
> > >
> > > Long story short, your first point is up for discussion. If more people
> > > want overrides located elsewhere, then that's fine by me. Regarding
> your
> > > second point, I think the current approach is good and people would
> have
> > to
> > > provide strong arguments to convince me of a different approach.
> > >
> > > Again, thanks for the feedback, it's really appreciated and if you have
> > > more, please let me know.
> > >
> > > Kind regards,
> > > Enno
> > >
> > > ________________________________
> > > From: Delany <de...@gmail.com>
> > > Sent: Sunday, November 21, 2021 4:46 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > Hi Enno,
> > >
> > > 2 things. I'd want to emphasise that the resolution of dependency
> > > management info and the dependency overrides (more like a reactor
> > > management concern) are independent of one another. Can achieve by
> > > promoting the tag to project.
> > >
> > > Then why not use the existing dependency tag to define the
> > replacement(s).
> > > Accept 0, 1 or many.
> > >
> > > ...
> > > <groupId>a</groupId>
> > > <artifactId>a</artifactId>
> > > <dependencyOverrides>
> > > <dependencyOverride>
> > > <original>
> > > <groupId>y</groupId>
> > > <artifactId>y</artifactId>
> > > </original>
> > > <dependency>
> > > <groupId>z</groupId>
> > > <artifactId>z</artifactId>
> > > </dependency>
> > > <dependency>
> > > <groupId>q</groupId>
> > > <artifactId>q</artifactId>
> > > </dependency>
> > > </dependencyOverride>
> > > </dependencyOverrides>
> > > <dependencies>
> > > <dependency>
> > > <groupId>w</groupId>
> > > <artifactId>w</artifactId>
> > > </dependency>
> > > <dependency>
> > > <groupId>x</groupId>
> > > <artifactId>x</artifactId>
> > > </dependency>
> > > </dependencies>
> > > ...
> > >
> > >
> > > Regards,
> > > Delany
> > >
> > >
> > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <
> Enno.Thieleke@holisticon.de
> > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > it's been a while and I've made some progress regarding
> > > > overrides/replacements and wanted to share the current state.
> > > >
> > > > What's implemented/changed:
> > > >
> > > > * The POM version has been upgraded to 4.1.0 and will accept
> > > > /project/dependencyManagement/dependencyOverrides which in turn can
> > take
> > > > the coordinates of original and overriding artifacts.
> > > > * Overrides can be declared on any POM level in a hierarchy POMs
> > > (i.e.
> > > > parents and children.
> > > > * Overrides can be imported from other POMs using the existing
> > > > `import` scope for POMs in the dependencyManagement section.
> > > > * If the same original artifact is overridden on different
> levels,
> > > the
> > > > "most downstream" wins.
> > > > * An override *must* be accompanied by an entry in the
> > > > dependencyManagement section. Maven generates an error and halts, if
> > > that's
> > > > not the case.
> > > > * If an override is declared and consumed in the same effective
> > POM,
> > > > Maven generates a warning that the user should use the overriding
> > > artifact
> > > > instead of the original artifact.
> > > > * The dependencies of an effective POM remain untouched.
> Overrides
> > > are
> > > > declared in POMs, but the act of overriding is implemented in
> > > > maven-resolver.
> > > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> > > > interfaces needed additions. While some might consider this to be a
> > minor
> > > > change, I consider this to be a major change, because the interfaces
> > are
> > > > not (and cannot be, yet) sealed.
> > > > * It is possible to override overrides of transitive
> dependencies.
> > In
> > > > other words, it is possible to override overrides of POMs of
> > > dependencies.
> > > >
> > > > While working on this I thought about names for
> overrides/replacements.
> > > > I'm still open to suggestions and pretty much undecided. Another name
> > > that
> > > > popped into my head is `dropinReplacements`, because it makes the
> > intent
> > > > very clear.
> > > >
> > > > For those of you who are interested, here are the links to the code
> > again
> > > > (so it's just one click away):
> > > >
> > > > *
> > > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> > > >
> > > > Also, I've rebased my changes onto master very recently.
> > > >
> > > > And here's the proposal itself:
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > >
> > > > If you find the time to look, please let me know what you think and
> > what
> > > > you think is missing.
> > > >
> > > > Kind regards
> > > > Enno
> > > >
> > > > ________________________________
> > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > Sent: Sunday, September 5, 2021 8:34 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > > A few notes on the proposal:
> > > >
> > > >
> > > > - Leave a dependency graph virtually untouched.
> > > > Only change/override nodes in place. Don't exclude dependencies
> and
> > > > include new ones on a different level in the graph.
> > > >
> > > > Think, whatever it means, served dependencies in mojo shouldnt have
> to
> > > rely
> > > > on this new section using getXArtifact or dependency visitor. No real
> > > good
> > > > reason to break everyone there.
> > > >
> > > > A not used override must break the build (it is an unexpected bug and
> > > would
> > > > make the dev life hard otherwise). I perfectly see that it will break
> > > > building a submodule in several cases but otherwise the section will
> > > become
> > > > unmanageable with time (see hibernate or cxf example) and since you
> > loose
> > > > the dependency relationship with this option compared to exclusions,
> it
> > > way
> > > > too much work to maintain it in practise. (This is why I think it
> > > shouldnt
> > > > be done this way but very worse case at dependency level giving hints
> > for
> > > > overrides and not elsewhere, mixed with dependency managementnit is
> > > trivial
> > > > to handle and maintain then).
> > > >
> > > > Pom rewriter must handle this section by dropping it and replacing it
> > by
> > > > exludes to keep compatibility with 3rd party resolvers (deployment).
> > > >
> > > > Overall, I still think it would be neat to see it as an extension for
> > > maven
> > > > 3.8.2 or 4 to be testable and validate design choices and actual
> usage
> > on
> > > > real dependencies compared to current option.
> > > >
> > > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> > Enno.Thieleke@holisticon.de
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > Hello again,
> > > > >
> > > > > I tried to create a proposal in/under
> > > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > > ,
> > > > > but I'm not allowed to, which makes sense since I'm new to the
> wiki,
> > > so I
> > > > > committed a proposal to my fork:
> > > > >
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > > >
> > > > > The current version probably still contains errors and misses
> details
> > > but
> > > > > I imo they need to be worked out in a group effort.
> > > > >
> > > > > Some feedback/comments would be appreciated.
> > > > >
> > > > > Maybe you could create a proposal page in your wiki and grant me
> edit
> > > > > rights (user eth)?
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > >
> > > > > ________________________________
> > > > > From: Enno Thieleke <En...@holisticon.de>
> > > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > > To: Maven Developers List <de...@maven.apache.org>
> > > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > > >
> > > > > Hi Michael,
> > > > >
> > > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > > >
> > > > > Just a few more questions before I start.
> > > > >
> > > > > For the issue: Would reopening
> > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would
> you
> > > like
> > > > > to see a new one?
> > > > >
> > > > > Where do I create the proposal?
> > > > >
> > > > > What should be created first, the issue or the proposal? I'm
> asking,
> > > > > because in the proposal we'd work out the details and after that's
> > > done,
> > > > > that's where the issue becomes relevant (no issue, no code
> changes).
> > At
> > > > > least that's how I'm used to implementing changes like this. I
> don't
> > > want
> > > > > to have created unnecessary noise in your issue system, if - for
> some
> > > > > unknown eventuality - the proposal doesn't get your approval.
> > > > >
> > > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > > maven-resolver?
> > > > >
> > > > > Kind regards
> > > > > Enno
> > > > > ________________________________
> > > > > From: Michael Osipov <mi...@apache.org>
> > > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
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 <rm...@gmail.com>
Sent: Monday, November 22, 2021 11:00 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
Hi all,
I fear not defining the version is likely a source of big issues and worse
than not having this feature at all since often, when you change the major,
you change totally the dependency and the override will just not work.
You can indeed say you must not have 2 dependencies in different versions
but it is what it is and it is not that uncommon - in particular for libs
(and if you want to force a single version you use dependency management).
So if this feature is desired I fear it must include the version and likely
manage the classifier as well to work.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 22 nov. 2021 à 10:14, Delany <de...@gmail.com> a écrit :
> Hi Enno,
>
> On point 1, figuring out the order of events in a build can be challenging
> for newbies since Maven is declarative. For example profiles are resolved
> early on and this is reflected by their place in the pom. Although that's
> really about config composition, having the overrides under project could
> also hint at their special nature. No strong argument to make.
>
> Point 2, you say you are following a separation of concerns, but it seems
> rather you are forcing one. By requiring dependency management the result
> is a tight coupling between stages of resolving the final dependencies (not
> being self-contained, you probably *should* make dependencyOverrides a
> child of dependencyManagement).
> Maven doesn't require managing dependencies, but your overrides do. There's
> no harm in picking up config provided by DM, but why force the
> relationship? If someone wants to add an exclude at the time of an
> override, frankly that should just be "not your problem". Reusing an
> existing structure is surely preferable to inventing another one? Would the
> enforcer rules have to learn about your new structure?
> I see why you went the path of only groupId:artifactId - you copied the
> exclusion structure. But then excluding doesn't require DM.
>
> You're right about wrapping the lists. Will you at least allow not defining
> a dependency at all, aka a global exclude?
>
> Delany
>
> On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <En...@holisticon.de>
> wrote:
>
> > Hi, Delany,
> >
> > thanks for the feedback.
> >
> > I get your point that management and overrides can be seen as
> independent.
> > To be honest, I'm really not picky about where in the POM overrides
> should
> > be located. I was hoping for opinions on this from others (and was not
> > disappointed) and at least one strong opinion from the Maven core team.
> As
> > to why I put overrides in the management section in the first place:
> simply
> > because I saw overrides as a management subject.
> >
> > About using the existing dependency tag to define replacements: I tried
> > that (in a way, I still used a different tag name though). The issue I
> have
> > with it is that the dependency tag can also take version, exclusions,
> > optional, etc. and I want that to be in the
> > /project/dependencyManagement/dependencies section. I'm applying the
> > separation of concerns principle here: overrides should simply map
> artifact
> > coordinates whereas managed dependencies are all about the right versions
> > and such. Or maybe the managed dependencies should also provide the
> > override information? The entire existing implementation can still be
> > changed with little effort.
> >
> > I also thought about allowing 0..n overrides for one original, but I
> > decided to make it a 1:1 mapping. Let me explain: First, I think it is
> > currently not possible to have lists in POMs without a wrapping element.
> > One would have to write:
> >
> > <!-- Simplified code for brevity -->
> > <dependencyOverrides>
> > <dependencyOverride>
> > <original/>
> > <dependencies>
> > <dependency/>
> > ...
> > </dependencies>
> > </dependencyOverride>
> > </dependencyOverrides>
> >
> > Please correct me on this if I'm wrong. Second, I think most of the time
> > people will be having 1:1 mappings anyway and with that in mind, having
> the
> > need to use lists which require a wrapping element would bloat a POM.
> >
> > Long story short, your first point is up for discussion. If more people
> > want overrides located elsewhere, then that's fine by me. Regarding your
> > second point, I think the current approach is good and people would have
> to
> > provide strong arguments to convince me of a different approach.
> >
> > Again, thanks for the feedback, it's really appreciated and if you have
> > more, please let me know.
> >
> > Kind regards,
> > Enno
> >
> > ________________________________
> > From: Delany <de...@gmail.com>
> > Sent: Sunday, November 21, 2021 4:46 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi Enno,
> >
> > 2 things. I'd want to emphasise that the resolution of dependency
> > management info and the dependency overrides (more like a reactor
> > management concern) are independent of one another. Can achieve by
> > promoting the tag to project.
> >
> > Then why not use the existing dependency tag to define the
> replacement(s).
> > Accept 0, 1 or many.
> >
> > ...
> > <groupId>a</groupId>
> > <artifactId>a</artifactId>
> > <dependencyOverrides>
> > <dependencyOverride>
> > <original>
> > <groupId>y</groupId>
> > <artifactId>y</artifactId>
> > </original>
> > <dependency>
> > <groupId>z</groupId>
> > <artifactId>z</artifactId>
> > </dependency>
> > <dependency>
> > <groupId>q</groupId>
> > <artifactId>q</artifactId>
> > </dependency>
> > </dependencyOverride>
> > </dependencyOverrides>
> > <dependencies>
> > <dependency>
> > <groupId>w</groupId>
> > <artifactId>w</artifactId>
> > </dependency>
> > <dependency>
> > <groupId>x</groupId>
> > <artifactId>x</artifactId>
> > </dependency>
> > </dependencies>
> > ...
> >
> >
> > Regards,
> > Delany
> >
> >
> > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <Enno.Thieleke@holisticon.de
> >
> > wrote:
> >
> > > Hello,
> > >
> > > it's been a while and I've made some progress regarding
> > > overrides/replacements and wanted to share the current state.
> > >
> > > What's implemented/changed:
> > >
> > > * The POM version has been upgraded to 4.1.0 and will accept
> > > /project/dependencyManagement/dependencyOverrides which in turn can
> take
> > > the coordinates of original and overriding artifacts.
> > > * Overrides can be declared on any POM level in a hierarchy POMs
> > (i.e.
> > > parents and children.
> > > * Overrides can be imported from other POMs using the existing
> > > `import` scope for POMs in the dependencyManagement section.
> > > * If the same original artifact is overridden on different levels,
> > the
> > > "most downstream" wins.
> > > * An override *must* be accompanied by an entry in the
> > > dependencyManagement section. Maven generates an error and halts, if
> > that's
> > > not the case.
> > > * If an override is declared and consumed in the same effective
> POM,
> > > Maven generates a warning that the user should use the overriding
> > artifact
> > > instead of the original artifact.
> > > * The dependencies of an effective POM remain untouched. Overrides
> > are
> > > declared in POMs, but the act of overriding is implemented in
> > > maven-resolver.
> > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> > > interfaces needed additions. While some might consider this to be a
> minor
> > > change, I consider this to be a major change, because the interfaces
> are
> > > not (and cannot be, yet) sealed.
> > > * It is possible to override overrides of transitive dependencies.
> In
> > > other words, it is possible to override overrides of POMs of
> > dependencies.
> > >
> > > While working on this I thought about names for overrides/replacements.
> > > I'm still open to suggestions and pretty much undecided. Another name
> > that
> > > popped into my head is `dropinReplacements`, because it makes the
> intent
> > > very clear.
> > >
> > > For those of you who are interested, here are the links to the code
> again
> > > (so it's just one click away):
> > >
> > > *
> > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> > >
> > > Also, I've rebased my changes onto master very recently.
> > >
> > > And here's the proposal itself:
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > >
> > > If you find the time to look, please let me know what you think and
> what
> > > you think is missing.
> > >
> > > Kind regards
> > > Enno
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Sunday, September 5, 2021 8:34 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > A few notes on the proposal:
> > >
> > >
> > > - Leave a dependency graph virtually untouched.
> > > Only change/override nodes in place. Don't exclude dependencies and
> > > include new ones on a different level in the graph.
> > >
> > > Think, whatever it means, served dependencies in mojo shouldnt have to
> > rely
> > > on this new section using getXArtifact or dependency visitor. No real
> > good
> > > reason to break everyone there.
> > >
> > > A not used override must break the build (it is an unexpected bug and
> > would
> > > make the dev life hard otherwise). I perfectly see that it will break
> > > building a submodule in several cases but otherwise the section will
> > become
> > > unmanageable with time (see hibernate or cxf example) and since you
> loose
> > > the dependency relationship with this option compared to exclusions, it
> > way
> > > too much work to maintain it in practise. (This is why I think it
> > shouldnt
> > > be done this way but very worse case at dependency level giving hints
> for
> > > overrides and not elsewhere, mixed with dependency managementnit is
> > trivial
> > > to handle and maintain then).
> > >
> > > Pom rewriter must handle this section by dropping it and replacing it
> by
> > > exludes to keep compatibility with 3rd party resolvers (deployment).
> > >
> > > Overall, I still think it would be neat to see it as an extension for
> > maven
> > > 3.8.2 or 4 to be testable and validate design choices and actual usage
> on
> > > real dependencies compared to current option.
> > >
> > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> Enno.Thieleke@holisticon.de
> > >
> > > a
> > > écrit :
> > >
> > > > Hello again,
> > > >
> > > > I tried to create a proposal in/under
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > ,
> > > > but I'm not allowed to, which makes sense since I'm new to the wiki,
> > so I
> > > > committed a proposal to my fork:
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > >
> > > > The current version probably still contains errors and misses details
> > but
> > > > I imo they need to be worked out in a group effort.
> > > >
> > > > Some feedback/comments would be appreciated.
> > > >
> > > > Maybe you could create a proposal page in your wiki and grant me edit
> > > > rights (user eth)?
> > > >
> > > > Kind regards
> > > > Enno
> > > >
> > > > ________________________________
> > > > From: Enno Thieleke <En...@holisticon.de>
> > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > > Hi Michael,
> > > >
> > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > >
> > > > Just a few more questions before I start.
> > > >
> > > > For the issue: Would reopening
> > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would you
> > like
> > > > to see a new one?
> > > >
> > > > Where do I create the proposal?
> > > >
> > > > What should be created first, the issue or the proposal? I'm asking,
> > > > because in the proposal we'd work out the details and after that's
> > done,
> > > > that's where the issue becomes relevant (no issue, no code changes).
> At
> > > > least that's how I'm used to implementing changes like this. I don't
> > want
> > > > to have created unnecessary noise in your issue system, if - for some
> > > > unknown eventuality - the proposal doesn't get your approval.
> > > >
> > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > maven-resolver?
> > > >
> > > > Kind regards
> > > > Enno
> > > > ________________________________
> > > > From: Michael Osipov <mi...@apache.org>
> > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <de...@gmail.com> a écrit :
> Hi Enno,
>
> On point 1, figuring out the order of events in a build can be challenging
> for newbies since Maven is declarative. For example profiles are resolved
> early on and this is reflected by their place in the pom. Although that's
> really about config composition, having the overrides under project could
> also hint at their special nature. No strong argument to make.
>
> Point 2, you say you are following a separation of concerns, but it seems
> rather you are forcing one. By requiring dependency management the result
> is a tight coupling between stages of resolving the final dependencies (not
> being self-contained, you probably *should* make dependencyOverrides a
> child of dependencyManagement).
> Maven doesn't require managing dependencies, but your overrides do. There's
> no harm in picking up config provided by DM, but why force the
> relationship? If someone wants to add an exclude at the time of an
> override, frankly that should just be "not your problem". Reusing an
> existing structure is surely preferable to inventing another one? Would the
> enforcer rules have to learn about your new structure?
> I see why you went the path of only groupId:artifactId - you copied the
> exclusion structure. But then excluding doesn't require DM.
>
> You're right about wrapping the lists. Will you at least allow not defining
> a dependency at all, aka a global exclude?
>
> Delany
>
> On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <En...@holisticon.de>
> wrote:
>
> > Hi, Delany,
> >
> > thanks for the feedback.
> >
> > I get your point that management and overrides can be seen as
> independent.
> > To be honest, I'm really not picky about where in the POM overrides
> should
> > be located. I was hoping for opinions on this from others (and was not
> > disappointed) and at least one strong opinion from the Maven core team.
> As
> > to why I put overrides in the management section in the first place:
> simply
> > because I saw overrides as a management subject.
> >
> > About using the existing dependency tag to define replacements: I tried
> > that (in a way, I still used a different tag name though). The issue I
> have
> > with it is that the dependency tag can also take version, exclusions,
> > optional, etc. and I want that to be in the
> > /project/dependencyManagement/dependencies section. I'm applying the
> > separation of concerns principle here: overrides should simply map
> artifact
> > coordinates whereas managed dependencies are all about the right versions
> > and such. Or maybe the managed dependencies should also provide the
> > override information? The entire existing implementation can still be
> > changed with little effort.
> >
> > I also thought about allowing 0..n overrides for one original, but I
> > decided to make it a 1:1 mapping. Let me explain: First, I think it is
> > currently not possible to have lists in POMs without a wrapping element.
> > One would have to write:
> >
> > <!-- Simplified code for brevity -->
> > <dependencyOverrides>
> > <dependencyOverride>
> > <original/>
> > <dependencies>
> > <dependency/>
> > ...
> > </dependencies>
> > </dependencyOverride>
> > </dependencyOverrides>
> >
> > Please correct me on this if I'm wrong. Second, I think most of the time
> > people will be having 1:1 mappings anyway and with that in mind, having
> the
> > need to use lists which require a wrapping element would bloat a POM.
> >
> > Long story short, your first point is up for discussion. If more people
> > want overrides located elsewhere, then that's fine by me. Regarding your
> > second point, I think the current approach is good and people would have
> to
> > provide strong arguments to convince me of a different approach.
> >
> > Again, thanks for the feedback, it's really appreciated and if you have
> > more, please let me know.
> >
> > Kind regards,
> > Enno
> >
> > ________________________________
> > From: Delany <de...@gmail.com>
> > Sent: Sunday, November 21, 2021 4:46 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi Enno,
> >
> > 2 things. I'd want to emphasise that the resolution of dependency
> > management info and the dependency overrides (more like a reactor
> > management concern) are independent of one another. Can achieve by
> > promoting the tag to project.
> >
> > Then why not use the existing dependency tag to define the
> replacement(s).
> > Accept 0, 1 or many.
> >
> > ...
> > <groupId>a</groupId>
> > <artifactId>a</artifactId>
> > <dependencyOverrides>
> > <dependencyOverride>
> > <original>
> > <groupId>y</groupId>
> > <artifactId>y</artifactId>
> > </original>
> > <dependency>
> > <groupId>z</groupId>
> > <artifactId>z</artifactId>
> > </dependency>
> > <dependency>
> > <groupId>q</groupId>
> > <artifactId>q</artifactId>
> > </dependency>
> > </dependencyOverride>
> > </dependencyOverrides>
> > <dependencies>
> > <dependency>
> > <groupId>w</groupId>
> > <artifactId>w</artifactId>
> > </dependency>
> > <dependency>
> > <groupId>x</groupId>
> > <artifactId>x</artifactId>
> > </dependency>
> > </dependencies>
> > ...
> >
> >
> > Regards,
> > Delany
> >
> >
> > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <Enno.Thieleke@holisticon.de
> >
> > wrote:
> >
> > > Hello,
> > >
> > > it's been a while and I've made some progress regarding
> > > overrides/replacements and wanted to share the current state.
> > >
> > > What's implemented/changed:
> > >
> > > * The POM version has been upgraded to 4.1.0 and will accept
> > > /project/dependencyManagement/dependencyOverrides which in turn can
> take
> > > the coordinates of original and overriding artifacts.
> > > * Overrides can be declared on any POM level in a hierarchy POMs
> > (i.e.
> > > parents and children.
> > > * Overrides can be imported from other POMs using the existing
> > > `import` scope for POMs in the dependencyManagement section.
> > > * If the same original artifact is overridden on different levels,
> > the
> > > "most downstream" wins.
> > > * An override *must* be accompanied by an entry in the
> > > dependencyManagement section. Maven generates an error and halts, if
> > that's
> > > not the case.
> > > * If an override is declared and consumed in the same effective
> POM,
> > > Maven generates a warning that the user should use the overriding
> > artifact
> > > instead of the original artifact.
> > > * The dependencies of an effective POM remain untouched. Overrides
> > are
> > > declared in POMs, but the act of overriding is implemented in
> > > maven-resolver.
> > > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> > > interfaces needed additions. While some might consider this to be a
> minor
> > > change, I consider this to be a major change, because the interfaces
> are
> > > not (and cannot be, yet) sealed.
> > > * It is possible to override overrides of transitive dependencies.
> In
> > > other words, it is possible to override overrides of POMs of
> > dependencies.
> > >
> > > While working on this I thought about names for overrides/replacements.
> > > I'm still open to suggestions and pretty much undecided. Another name
> > that
> > > popped into my head is `dropinReplacements`, because it makes the
> intent
> > > very clear.
> > >
> > > For those of you who are interested, here are the links to the code
> again
> > > (so it's just one click away):
> > >
> > > *
> > https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> > >
> > > Also, I've rebased my changes onto master very recently.
> > >
> > > And here's the proposal itself:
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > >
> > > If you find the time to look, please let me know what you think and
> what
> > > you think is missing.
> > >
> > > Kind regards
> > > Enno
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Sunday, September 5, 2021 8:34 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > A few notes on the proposal:
> > >
> > >
> > > - Leave a dependency graph virtually untouched.
> > > Only change/override nodes in place. Don't exclude dependencies and
> > > include new ones on a different level in the graph.
> > >
> > > Think, whatever it means, served dependencies in mojo shouldnt have to
> > rely
> > > on this new section using getXArtifact or dependency visitor. No real
> > good
> > > reason to break everyone there.
> > >
> > > A not used override must break the build (it is an unexpected bug and
> > would
> > > make the dev life hard otherwise). I perfectly see that it will break
> > > building a submodule in several cases but otherwise the section will
> > become
> > > unmanageable with time (see hibernate or cxf example) and since you
> loose
> > > the dependency relationship with this option compared to exclusions, it
> > way
> > > too much work to maintain it in practise. (This is why I think it
> > shouldnt
> > > be done this way but very worse case at dependency level giving hints
> for
> > > overrides and not elsewhere, mixed with dependency managementnit is
> > trivial
> > > to handle and maintain then).
> > >
> > > Pom rewriter must handle this section by dropping it and replacing it
> by
> > > exludes to keep compatibility with 3rd party resolvers (deployment).
> > >
> > > Overall, I still think it would be neat to see it as an extension for
> > maven
> > > 3.8.2 or 4 to be testable and validate design choices and actual usage
> on
> > > real dependencies compared to current option.
> > >
> > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <
> Enno.Thieleke@holisticon.de
> > >
> > > a
> > > écrit :
> > >
> > > > Hello again,
> > > >
> > > > I tried to create a proposal in/under
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > > ,
> > > > but I'm not allowed to, which makes sense since I'm new to the wiki,
> > so I
> > > > committed a proposal to my fork:
> > > >
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > > >
> > > > The current version probably still contains errors and misses details
> > but
> > > > I imo they need to be worked out in a group effort.
> > > >
> > > > Some feedback/comments would be appreciated.
> > > >
> > > > Maybe you could create a proposal page in your wiki and grant me edit
> > > > rights (user eth)?
> > > >
> > > > Kind regards
> > > > Enno
> > > >
> > > > ________________________________
> > > > From: Enno Thieleke <En...@holisticon.de>
> > > > Sent: Thursday, August 26, 2021 11:59 AM
> > > > To: Maven Developers List <de...@maven.apache.org>
> > > > Subject: Re: Request for Enhancement: Dependency Overrides
> > > >
> > > > Hi Michael,
> > > >
> > > > I'll take this as a "go ahead, if it's good we'll accept it".
> > > >
> > > > Just a few more questions before I start.
> > > >
> > > > For the issue: Would reopening
> > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would you
> > like
> > > > to see a new one?
> > > >
> > > > Where do I create the proposal?
> > > >
> > > > What should be created first, the issue or the proposal? I'm asking,
> > > > because in the proposal we'd work out the details and after that's
> > done,
> > > > that's where the issue becomes relevant (no issue, no code changes).
> At
> > > > least that's how I'm used to implementing changes like this. I don't
> > want
> > > > to have created unnecessary noise in your issue system, if - for some
> > > > unknown eventuality - the proposal doesn't get your approval.
> > > >
> > > > Is it ok to use one issue for changes in both projects, Maven and
> > > > maven-resolver?
> > > >
> > > > Kind regards
> > > > Enno
> > > > ________________________________
> > > > From: Michael Osipov <mi...@apache.org>
> > > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Delany <de...@gmail.com>.
Hi Enno,
On point 1, figuring out the order of events in a build can be challenging
for newbies since Maven is declarative. For example profiles are resolved
early on and this is reflected by their place in the pom. Although that's
really about config composition, having the overrides under project could
also hint at their special nature. No strong argument to make.
Point 2, you say you are following a separation of concerns, but it seems
rather you are forcing one. By requiring dependency management the result
is a tight coupling between stages of resolving the final dependencies (not
being self-contained, you probably *should* make dependencyOverrides a
child of dependencyManagement).
Maven doesn't require managing dependencies, but your overrides do. There's
no harm in picking up config provided by DM, but why force the
relationship? If someone wants to add an exclude at the time of an
override, frankly that should just be "not your problem". Reusing an
existing structure is surely preferable to inventing another one? Would the
enforcer rules have to learn about your new structure?
I see why you went the path of only groupId:artifactId - you copied the
exclusion structure. But then excluding doesn't require DM.
You're right about wrapping the lists. Will you at least allow not defining
a dependency at all, aka a global exclude?
Delany
On Sun, 21 Nov 2021 at 17:14, Enno Thieleke <En...@holisticon.de>
wrote:
> Hi, Delany,
>
> thanks for the feedback.
>
> I get your point that management and overrides can be seen as independent.
> To be honest, I'm really not picky about where in the POM overrides should
> be located. I was hoping for opinions on this from others (and was not
> disappointed) and at least one strong opinion from the Maven core team. As
> to why I put overrides in the management section in the first place: simply
> because I saw overrides as a management subject.
>
> About using the existing dependency tag to define replacements: I tried
> that (in a way, I still used a different tag name though). The issue I have
> with it is that the dependency tag can also take version, exclusions,
> optional, etc. and I want that to be in the
> /project/dependencyManagement/dependencies section. I'm applying the
> separation of concerns principle here: overrides should simply map artifact
> coordinates whereas managed dependencies are all about the right versions
> and such. Or maybe the managed dependencies should also provide the
> override information? The entire existing implementation can still be
> changed with little effort.
>
> I also thought about allowing 0..n overrides for one original, but I
> decided to make it a 1:1 mapping. Let me explain: First, I think it is
> currently not possible to have lists in POMs without a wrapping element.
> One would have to write:
>
> <!-- Simplified code for brevity -->
> <dependencyOverrides>
> <dependencyOverride>
> <original/>
> <dependencies>
> <dependency/>
> ...
> </dependencies>
> </dependencyOverride>
> </dependencyOverrides>
>
> Please correct me on this if I'm wrong. Second, I think most of the time
> people will be having 1:1 mappings anyway and with that in mind, having the
> need to use lists which require a wrapping element would bloat a POM.
>
> Long story short, your first point is up for discussion. If more people
> want overrides located elsewhere, then that's fine by me. Regarding your
> second point, I think the current approach is good and people would have to
> provide strong arguments to convince me of a different approach.
>
> Again, thanks for the feedback, it's really appreciated and if you have
> more, please let me know.
>
> Kind regards,
> Enno
>
> ________________________________
> From: Delany <de...@gmail.com>
> Sent: Sunday, November 21, 2021 4:46 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi Enno,
>
> 2 things. I'd want to emphasise that the resolution of dependency
> management info and the dependency overrides (more like a reactor
> management concern) are independent of one another. Can achieve by
> promoting the tag to project.
>
> Then why not use the existing dependency tag to define the replacement(s).
> Accept 0, 1 or many.
>
> ...
> <groupId>a</groupId>
> <artifactId>a</artifactId>
> <dependencyOverrides>
> <dependencyOverride>
> <original>
> <groupId>y</groupId>
> <artifactId>y</artifactId>
> </original>
> <dependency>
> <groupId>z</groupId>
> <artifactId>z</artifactId>
> </dependency>
> <dependency>
> <groupId>q</groupId>
> <artifactId>q</artifactId>
> </dependency>
> </dependencyOverride>
> </dependencyOverrides>
> <dependencies>
> <dependency>
> <groupId>w</groupId>
> <artifactId>w</artifactId>
> </dependency>
> <dependency>
> <groupId>x</groupId>
> <artifactId>x</artifactId>
> </dependency>
> </dependencies>
> ...
>
>
> Regards,
> Delany
>
>
> On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <En...@holisticon.de>
> wrote:
>
> > Hello,
> >
> > it's been a while and I've made some progress regarding
> > overrides/replacements and wanted to share the current state.
> >
> > What's implemented/changed:
> >
> > * The POM version has been upgraded to 4.1.0 and will accept
> > /project/dependencyManagement/dependencyOverrides which in turn can take
> > the coordinates of original and overriding artifacts.
> > * Overrides can be declared on any POM level in a hierarchy POMs
> (i.e.
> > parents and children.
> > * Overrides can be imported from other POMs using the existing
> > `import` scope for POMs in the dependencyManagement section.
> > * If the same original artifact is overridden on different levels,
> the
> > "most downstream" wins.
> > * An override *must* be accompanied by an entry in the
> > dependencyManagement section. Maven generates an error and halts, if
> that's
> > not the case.
> > * If an override is declared and consumed in the same effective POM,
> > Maven generates a warning that the user should use the overriding
> artifact
> > instead of the original artifact.
> > * The dependencies of an effective POM remain untouched. Overrides
> are
> > declared in POMs, but the act of overriding is implemented in
> > maven-resolver.
> > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> > interfaces needed additions. While some might consider this to be a minor
> > change, I consider this to be a major change, because the interfaces are
> > not (and cannot be, yet) sealed.
> > * It is possible to override overrides of transitive dependencies. In
> > other words, it is possible to override overrides of POMs of
> dependencies.
> >
> > While working on this I thought about names for overrides/replacements.
> > I'm still open to suggestions and pretty much undecided. Another name
> that
> > popped into my head is `dropinReplacements`, because it makes the intent
> > very clear.
> >
> > For those of you who are interested, here are the links to the code again
> > (so it's just one click away):
> >
> > *
> https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> > * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> > * https://github.com/strohmattenverleger/maven-MNG-4530-example
> >
> > Also, I've rebased my changes onto master very recently.
> >
> > And here's the proposal itself:
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> >
> > If you find the time to look, please let me know what you think and what
> > you think is missing.
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Sunday, September 5, 2021 8:34 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > A few notes on the proposal:
> >
> >
> > - Leave a dependency graph virtually untouched.
> > Only change/override nodes in place. Don't exclude dependencies and
> > include new ones on a different level in the graph.
> >
> > Think, whatever it means, served dependencies in mojo shouldnt have to
> rely
> > on this new section using getXArtifact or dependency visitor. No real
> good
> > reason to break everyone there.
> >
> > A not used override must break the build (it is an unexpected bug and
> would
> > make the dev life hard otherwise). I perfectly see that it will break
> > building a submodule in several cases but otherwise the section will
> become
> > unmanageable with time (see hibernate or cxf example) and since you loose
> > the dependency relationship with this option compared to exclusions, it
> way
> > too much work to maintain it in practise. (This is why I think it
> shouldnt
> > be done this way but very worse case at dependency level giving hints for
> > overrides and not elsewhere, mixed with dependency managementnit is
> trivial
> > to handle and maintain then).
> >
> > Pom rewriter must handle this section by dropping it and replacing it by
> > exludes to keep compatibility with 3rd party resolvers (deployment).
> >
> > Overall, I still think it would be neat to see it as an extension for
> maven
> > 3.8.2 or 4 to be testable and validate design choices and actual usage on
> > real dependencies compared to current option.
> >
> > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <Enno.Thieleke@holisticon.de
> >
> > a
> > écrit :
> >
> > > Hello again,
> > >
> > > I tried to create a proposal in/under
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> > ,
> > > but I'm not allowed to, which makes sense since I'm new to the wiki,
> so I
> > > committed a proposal to my fork:
> > >
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> > >
> > > The current version probably still contains errors and misses details
> but
> > > I imo they need to be worked out in a group effort.
> > >
> > > Some feedback/comments would be appreciated.
> > >
> > > Maybe you could create a proposal page in your wiki and grant me edit
> > > rights (user eth)?
> > >
> > > Kind regards
> > > Enno
> > >
> > > ________________________________
> > > From: Enno Thieleke <En...@holisticon.de>
> > > Sent: Thursday, August 26, 2021 11:59 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Subject: Re: Request for Enhancement: Dependency Overrides
> > >
> > > Hi Michael,
> > >
> > > I'll take this as a "go ahead, if it's good we'll accept it".
> > >
> > > Just a few more questions before I start.
> > >
> > > For the issue: Would reopening
> > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would you
> like
> > > to see a new one?
> > >
> > > Where do I create the proposal?
> > >
> > > What should be created first, the issue or the proposal? I'm asking,
> > > because in the proposal we'd work out the details and after that's
> done,
> > > that's where the issue becomes relevant (no issue, no code changes). At
> > > least that's how I'm used to implementing changes like this. I don't
> want
> > > to have created unnecessary noise in your issue system, if - for some
> > > unknown eventuality - the proposal doesn't get your approval.
> > >
> > > Is it ok to use one issue for changes in both projects, Maven and
> > > maven-resolver?
> > >
> > > Kind regards
> > > Enno
> > > ________________________________
> > > From: Michael Osipov <mi...@apache.org>
> > > Sent: Wednesday, August 25, 2021 9:01 PM
> > > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
Hi, Delany,
thanks for the feedback.
I get your point that management and overrides can be seen as independent. To be honest, I'm really not picky about where in the POM overrides should be located. I was hoping for opinions on this from others (and was not disappointed) and at least one strong opinion from the Maven core team. As to why I put overrides in the management section in the first place: simply because I saw overrides as a management subject.
About using the existing dependency tag to define replacements: I tried that (in a way, I still used a different tag name though). The issue I have with it is that the dependency tag can also take version, exclusions, optional, etc. and I want that to be in the /project/dependencyManagement/dependencies section. I'm applying the separation of concerns principle here: overrides should simply map artifact coordinates whereas managed dependencies are all about the right versions and such. Or maybe the managed dependencies should also provide the override information? The entire existing implementation can still be changed with little effort.
I also thought about allowing 0..n overrides for one original, but I decided to make it a 1:1 mapping. Let me explain: First, I think it is currently not possible to have lists in POMs without a wrapping element. One would have to write:
<!-- Simplified code for brevity -->
<dependencyOverrides>
<dependencyOverride>
<original/>
<dependencies>
<dependency/>
...
</dependencies>
</dependencyOverride>
</dependencyOverrides>
Please correct me on this if I'm wrong. Second, I think most of the time people will be having 1:1 mappings anyway and with that in mind, having the need to use lists which require a wrapping element would bloat a POM.
Long story short, your first point is up for discussion. If more people want overrides located elsewhere, then that's fine by me. Regarding your second point, I think the current approach is good and people would have to provide strong arguments to convince me of a different approach.
Again, thanks for the feedback, it's really appreciated and if you have more, please let me know.
Kind regards,
Enno
________________________________
From: Delany <de...@gmail.com>
Sent: Sunday, November 21, 2021 4:46 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
Hi Enno,
2 things. I'd want to emphasise that the resolution of dependency
management info and the dependency overrides (more like a reactor
management concern) are independent of one another. Can achieve by
promoting the tag to project.
Then why not use the existing dependency tag to define the replacement(s).
Accept 0, 1 or many.
...
<groupId>a</groupId>
<artifactId>a</artifactId>
<dependencyOverrides>
<dependencyOverride>
<original>
<groupId>y</groupId>
<artifactId>y</artifactId>
</original>
<dependency>
<groupId>z</groupId>
<artifactId>z</artifactId>
</dependency>
<dependency>
<groupId>q</groupId>
<artifactId>q</artifactId>
</dependency>
</dependencyOverride>
</dependencyOverrides>
<dependencies>
<dependency>
<groupId>w</groupId>
<artifactId>w</artifactId>
</dependency>
<dependency>
<groupId>x</groupId>
<artifactId>x</artifactId>
</dependency>
</dependencies>
...
Regards,
Delany
On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <En...@holisticon.de>
wrote:
> Hello,
>
> it's been a while and I've made some progress regarding
> overrides/replacements and wanted to share the current state.
>
> What's implemented/changed:
>
> * The POM version has been upgraded to 4.1.0 and will accept
> /project/dependencyManagement/dependencyOverrides which in turn can take
> the coordinates of original and overriding artifacts.
> * Overrides can be declared on any POM level in a hierarchy POMs (i.e.
> parents and children.
> * Overrides can be imported from other POMs using the existing
> `import` scope for POMs in the dependencyManagement section.
> * If the same original artifact is overridden on different levels, the
> "most downstream" wins.
> * An override *must* be accompanied by an entry in the
> dependencyManagement section. Maven generates an error and halts, if that's
> not the case.
> * If an override is declared and consumed in the same effective POM,
> Maven generates a warning that the user should use the overriding artifact
> instead of the original artifact.
> * The dependencies of an effective POM remain untouched. Overrides are
> declared in POMs, but the act of overriding is implemented in
> maven-resolver.
> * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> interfaces needed additions. While some might consider this to be a minor
> change, I consider this to be a major change, because the interfaces are
> not (and cannot be, yet) sealed.
> * It is possible to override overrides of transitive dependencies. In
> other words, it is possible to override overrides of POMs of dependencies.
>
> While working on this I thought about names for overrides/replacements.
> I'm still open to suggestions and pretty much undecided. Another name that
> popped into my head is `dropinReplacements`, because it makes the intent
> very clear.
>
> For those of you who are interested, here are the links to the code again
> (so it's just one click away):
>
> * https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> * https://github.com/strohmattenverleger/maven-MNG-4530-example
>
> Also, I've rebased my changes onto master very recently.
>
> And here's the proposal itself:
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
>
> If you find the time to look, please let me know what you think and what
> you think is missing.
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Sunday, September 5, 2021 8:34 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> A few notes on the proposal:
>
>
> - Leave a dependency graph virtually untouched.
> Only change/override nodes in place. Don't exclude dependencies and
> include new ones on a different level in the graph.
>
> Think, whatever it means, served dependencies in mojo shouldnt have to rely
> on this new section using getXArtifact or dependency visitor. No real good
> reason to break everyone there.
>
> A not used override must break the build (it is an unexpected bug and would
> make the dev life hard otherwise). I perfectly see that it will break
> building a submodule in several cases but otherwise the section will become
> unmanageable with time (see hibernate or cxf example) and since you loose
> the dependency relationship with this option compared to exclusions, it way
> too much work to maintain it in practise. (This is why I think it shouldnt
> be done this way but very worse case at dependency level giving hints for
> overrides and not elsewhere, mixed with dependency managementnit is trivial
> to handle and maintain then).
>
> Pom rewriter must handle this section by dropping it and replacing it by
> exludes to keep compatibility with 3rd party resolvers (deployment).
>
> Overall, I still think it would be neat to see it as an extension for maven
> 3.8.2 or 4 to be testable and validate design choices and actual usage on
> real dependencies compared to current option.
>
> Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <En...@holisticon.de>
> a
> écrit :
>
> > Hello again,
> >
> > I tried to create a proposal in/under
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> ,
> > but I'm not allowed to, which makes sense since I'm new to the wiki, so I
> > committed a proposal to my fork:
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> >
> > The current version probably still contains errors and misses details but
> > I imo they need to be worked out in a group effort.
> >
> > Some feedback/comments would be appreciated.
> >
> > Maybe you could create a proposal page in your wiki and grant me edit
> > rights (user eth)?
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Enno Thieleke <En...@holisticon.de>
> > Sent: Thursday, August 26, 2021 11:59 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi Michael,
> >
> > I'll take this as a "go ahead, if it's good we'll accept it".
> >
> > Just a few more questions before I start.
> >
> > For the issue: Would reopening
> > https://issues.apache.org/jira/browse/MNG-4530 suffice or would you like
> > to see a new one?
> >
> > Where do I create the proposal?
> >
> > What should be created first, the issue or the proposal? I'm asking,
> > because in the proposal we'd work out the details and after that's done,
> > that's where the issue becomes relevant (no issue, no code changes). At
> > least that's how I'm used to implementing changes like this. I don't want
> > to have created unnecessary noise in your issue system, if - for some
> > unknown eventuality - the proposal doesn't get your approval.
> >
> > Is it ok to use one issue for changes in both projects, Maven and
> > maven-resolver?
> >
> > Kind regards
> > Enno
> > ________________________________
> > From: Michael Osipov <mi...@apache.org>
> > Sent: Wednesday, August 25, 2021 9:01 PM
> > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Delany <de...@gmail.com>.
Hi Enno,
2 things. I'd want to emphasise that the resolution of dependency
management info and the dependency overrides (more like a reactor
management concern) are independent of one another. Can achieve by
promoting the tag to project.
Then why not use the existing dependency tag to define the replacement(s).
Accept 0, 1 or many.
...
<groupId>a</groupId>
<artifactId>a</artifactId>
<dependencyOverrides>
<dependencyOverride>
<original>
<groupId>y</groupId>
<artifactId>y</artifactId>
</original>
<dependency>
<groupId>z</groupId>
<artifactId>z</artifactId>
</dependency>
<dependency>
<groupId>q</groupId>
<artifactId>q</artifactId>
</dependency>
</dependencyOverride>
</dependencyOverrides>
<dependencies>
<dependency>
<groupId>w</groupId>
<artifactId>w</artifactId>
</dependency>
<dependency>
<groupId>x</groupId>
<artifactId>x</artifactId>
</dependency>
</dependencies>
...
Regards,
Delany
On Sun, 21 Nov 2021 at 02:05, Enno Thieleke <En...@holisticon.de>
wrote:
> Hello,
>
> it's been a while and I've made some progress regarding
> overrides/replacements and wanted to share the current state.
>
> What's implemented/changed:
>
> * The POM version has been upgraded to 4.1.0 and will accept
> /project/dependencyManagement/dependencyOverrides which in turn can take
> the coordinates of original and overriding artifacts.
> * Overrides can be declared on any POM level in a hierarchy POMs (i.e.
> parents and children.
> * Overrides can be imported from other POMs using the existing
> `import` scope for POMs in the dependencyManagement section.
> * If the same original artifact is overridden on different levels, the
> "most downstream" wins.
> * An override *must* be accompanied by an entry in the
> dependencyManagement section. Maven generates an error and halts, if that's
> not the case.
> * If an override is declared and consumed in the same effective POM,
> Maven generates a warning that the user should use the overriding artifact
> instead of the original artifact.
> * The dependencies of an effective POM remain untouched. Overrides are
> declared in POMs, but the act of overriding is implemented in
> maven-resolver.
> * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because
> interfaces needed additions. While some might consider this to be a minor
> change, I consider this to be a major change, because the interfaces are
> not (and cannot be, yet) sealed.
> * It is possible to override overrides of transitive dependencies. In
> other words, it is possible to override overrides of POMs of dependencies.
>
> While working on this I thought about names for overrides/replacements.
> I'm still open to suggestions and pretty much undecided. Another name that
> popped into my head is `dropinReplacements`, because it makes the intent
> very clear.
>
> For those of you who are interested, here are the links to the code again
> (so it's just one click away):
>
> * https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530
> * https://github.com/strohmattenverleger/maven/tree/MNG-4530
> * https://github.com/strohmattenverleger/maven-MNG-4530-example
>
> Also, I've rebased my changes onto master very recently.
>
> And here's the proposal itself:
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
>
> If you find the time to look, please let me know what you think and what
> you think is missing.
>
> Kind regards
> Enno
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Sunday, September 5, 2021 8:34 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> A few notes on the proposal:
>
>
> - Leave a dependency graph virtually untouched.
> Only change/override nodes in place. Don't exclude dependencies and
> include new ones on a different level in the graph.
>
> Think, whatever it means, served dependencies in mojo shouldnt have to rely
> on this new section using getXArtifact or dependency visitor. No real good
> reason to break everyone there.
>
> A not used override must break the build (it is an unexpected bug and would
> make the dev life hard otherwise). I perfectly see that it will break
> building a submodule in several cases but otherwise the section will become
> unmanageable with time (see hibernate or cxf example) and since you loose
> the dependency relationship with this option compared to exclusions, it way
> too much work to maintain it in practise. (This is why I think it shouldnt
> be done this way but very worse case at dependency level giving hints for
> overrides and not elsewhere, mixed with dependency managementnit is trivial
> to handle and maintain then).
>
> Pom rewriter must handle this section by dropping it and replacing it by
> exludes to keep compatibility with 3rd party resolvers (deployment).
>
> Overall, I still think it would be neat to see it as an extension for maven
> 3.8.2 or 4 to be testable and validate design choices and actual usage on
> real dependencies compared to current option.
>
> Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <En...@holisticon.de>
> a
> écrit :
>
> > Hello again,
> >
> > I tried to create a proposal in/under
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567
> ,
> > but I'm not allowed to, which makes sense since I'm new to the wiki, so I
> > committed a proposal to my fork:
> >
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
> >
> > The current version probably still contains errors and misses details but
> > I imo they need to be worked out in a group effort.
> >
> > Some feedback/comments would be appreciated.
> >
> > Maybe you could create a proposal page in your wiki and grant me edit
> > rights (user eth)?
> >
> > Kind regards
> > Enno
> >
> > ________________________________
> > From: Enno Thieleke <En...@holisticon.de>
> > Sent: Thursday, August 26, 2021 11:59 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Hi Michael,
> >
> > I'll take this as a "go ahead, if it's good we'll accept it".
> >
> > Just a few more questions before I start.
> >
> > For the issue: Would reopening
> > https://issues.apache.org/jira/browse/MNG-4530 suffice or would you like
> > to see a new one?
> >
> > Where do I create the proposal?
> >
> > What should be created first, the issue or the proposal? I'm asking,
> > because in the proposal we'd work out the details and after that's done,
> > that's where the issue becomes relevant (no issue, no code changes). At
> > least that's how I'm used to implementing changes like this. I don't want
> > to have created unnecessary noise in your issue system, if - for some
> > unknown eventuality - the proposal doesn't get your approval.
> >
> > Is it ok to use one issue for changes in both projects, Maven and
> > maven-resolver?
> >
> > Kind regards
> > Enno
> > ________________________________
> > From: Michael Osipov <mi...@apache.org>
> > Sent: Wednesday, August 25, 2021 9:01 PM
> > To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Request for Enhancement: Dependency Overrides
Posted by Enno Thieleke <En...@holisticon.de>.
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 <rm...@gmail.com>
Sent: Sunday, September 5, 2021 8:34 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Request for Enhancement: Dependency Overrides
A few notes on the proposal:
- Leave a dependency graph virtually untouched.
Only change/override nodes in place. Don't exclude dependencies and
include new ones on a different level in the graph.
Think, whatever it means, served dependencies in mojo shouldnt have to rely
on this new section using getXArtifact or dependency visitor. No real good
reason to break everyone there.
A not used override must break the build (it is an unexpected bug and would
make the dev life hard otherwise). I perfectly see that it will break
building a submodule in several cases but otherwise the section will become
unmanageable with time (see hibernate or cxf example) and since you loose
the dependency relationship with this option compared to exclusions, it way
too much work to maintain it in practise. (This is why I think it shouldnt
be done this way but very worse case at dependency level giving hints for
overrides and not elsewhere, mixed with dependency managementnit is trivial
to handle and maintain then).
Pom rewriter must handle this section by dropping it and replacing it by
exludes to keep compatibility with 3rd party resolvers (deployment).
Overall, I still think it would be neat to see it as an extension for maven
3.8.2 or 4 to be testable and validate design choices and actual usage on
real dependencies compared to current option.
Le sam. 4 sept. 2021 à 23:21, Enno Thieleke <En...@holisticon.de> a
écrit :
> Hello again,
>
> I tried to create a proposal in/under
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567,
> but I'm not allowed to, which makes sense since I'm new to the wiki, so I
> committed a proposal to my fork:
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
>
> The current version probably still contains errors and misses details but
> I imo they need to be worked out in a group effort.
>
> Some feedback/comments would be appreciated.
>
> Maybe you could create a proposal page in your wiki and grant me edit
> rights (user eth)?
>
> Kind regards
> Enno
>
> ________________________________
> From: Enno Thieleke <En...@holisticon.de>
> Sent: Thursday, August 26, 2021 11:59 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi Michael,
>
> I'll take this as a "go ahead, if it's good we'll accept it".
>
> Just a few more questions before I start.
>
> For the issue: Would reopening
> https://issues.apache.org/jira/browse/MNG-4530 suffice or would you like
> to see a new one?
>
> Where do I create the proposal?
>
> What should be created first, the issue or the proposal? I'm asking,
> because in the proposal we'd work out the details and after that's done,
> that's where the issue becomes relevant (no issue, no code changes). At
> least that's how I'm used to implementing changes like this. I don't want
> to have created unnecessary noise in your issue system, if - for some
> unknown eventuality - the proposal doesn't get your approval.
>
> Is it ok to use one issue for changes in both projects, Maven and
> maven-resolver?
>
> Kind regards
> Enno
> ________________________________
> From: Michael Osipov <mi...@apache.org>
> Sent: Wednesday, August 25, 2021 9:01 PM
> To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Request for Enhancement: Dependency Overrides
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <En...@holisticon.de> a
écrit :
> Hello again,
>
> I tried to create a proposal in/under
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567,
> but I'm not allowed to, which makes sense since I'm new to the wiki, so I
> committed a proposal to my fork:
> https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md
>
> The current version probably still contains errors and misses details but
> I imo they need to be worked out in a group effort.
>
> Some feedback/comments would be appreciated.
>
> Maybe you could create a proposal page in your wiki and grant me edit
> rights (user eth)?
>
> Kind regards
> Enno
>
> ________________________________
> From: Enno Thieleke <En...@holisticon.de>
> Sent: Thursday, August 26, 2021 11:59 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi Michael,
>
> I'll take this as a "go ahead, if it's good we'll accept it".
>
> Just a few more questions before I start.
>
> For the issue: Would reopening
> https://issues.apache.org/jira/browse/MNG-4530 suffice or would you like
> to see a new one?
>
> Where do I create the proposal?
>
> What should be created first, the issue or the proposal? I'm asking,
> because in the proposal we'd work out the details and after that's done,
> that's where the issue becomes relevant (no issue, no code changes). At
> least that's how I'm used to implementing changes like this. I don't want
> to have created unnecessary noise in your issue system, if - for some
> unknown eventuality - the proposal doesn't get your approval.
>
> Is it ok to use one issue for changes in both projects, Maven and
> maven-resolver?
>
> Kind regards
> Enno
> ________________________________
> From: Michael Osipov <mi...@apache.org>
> Sent: Wednesday, August 25, 2021 9:01 PM
> To: dev@maven.apache.org <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>