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
> >
> >
>
