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