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