[GitHub] [maven-site-plugin] dependabot[bot] opened a new pull request #60: Bump mavenVersion from 3.0.5 to 3.8.2

[GitBox]

dependabot[bot] opened a new pull request #60:
URL: https://github.com/apache/maven-site-plugin/pull/60


   Bumps `mavenVersion` from 3.0.5 to 3.8.2.
   Updates `maven-artifact` from 3.0.5 to 3.8.2
   
   Commits
   
   https://github.com/apache/maven/commit/ea98e05a04480131370aa0c110b8c54cf726c06f;>ea98e05
 [maven-release-plugin] prepare release maven-3.8.2
   https://github.com/apache/maven/commit/7ecdb3c970d71de3e48fe4de691388868ac03630;>7ecdb3c
 [MNG-7198] Upgrade SLF4J to 1.7.32
   https://github.com/apache/maven/commit/51f6d8b8525d8bf218f70100ec99a7ae97097923;>51f6d8b
 [MNG-7196] Upgrade Jansi to 2.3.4
   https://github.com/apache/maven/commit/f32eb09892686cba083f9f175b3c8eac0ac42ae7;>f32eb09
 [MNG-7010] Omit NB: JAVA_HOME should point to a JDK not a JRE
   https://github.com/apache/maven/commit/22a8cfa05976b23284388675dcabd7e5e8037fb0;>22a8cfa
 [MNG-6648] 'mavenrc_pre' script does not receive arguments like mavenrc in 
Bo...
   https://github.com/apache/maven/commit/b74199ed446c83282ad806afaf962a7f74eac0ea;>b74199e
 [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports
   https://github.com/apache/maven/commit/c395ca976dc9eaed65dcdc0037508d1edbfb57f3;>c395ca9
 [MNG-7190] add /usr/local/etc/mavenrc to reference documentation
   https://github.com/apache/maven/commit/25df095829bff8a1744db7dbf1ddd14aa1f8d43f;>25df095
 [MNG-7190] Load mavenrc from /usr/local/etc also in Bourne shell script
   https://github.com/apache/maven/commit/268f9565746175f5900670e372092e0c071d85bd;>268f956
 Use proper term: directory
   https://github.com/apache/maven/commit/176b272f30c4fbd62013b4702ab28518c21628ac;>176b272
 [MNG-7185] Describe explicit and recommended version for 
VersionRange.createF...
   Additional commits viewable in https://github.com/apache/maven/compare/maven-3.0.5...maven-3.8.2;>compare
 view
   
   
   
   
   Updates `maven-compat` from 3.0.5 to 3.8.2
   
   Commits
   
   https://github.com/apache/maven/commit/ea98e05a04480131370aa0c110b8c54cf726c06f;>ea98e05
 [maven-release-plugin] prepare release maven-3.8.2
   https://github.com/apache/maven/commit/7ecdb3c970d71de3e48fe4de691388868ac03630;>7ecdb3c
 [MNG-7198] Upgrade SLF4J to 1.7.32
   https://github.com/apache/maven/commit/51f6d8b8525d8bf218f70100ec99a7ae97097923;>51f6d8b
 [MNG-7196] Upgrade Jansi to 2.3.4
   https://github.com/apache/maven/commit/f32eb09892686cba083f9f175b3c8eac0ac42ae7;>f32eb09
 [MNG-7010] Omit NB: JAVA_HOME should point to a JDK not a JRE
   https://github.com/apache/maven/commit/22a8cfa05976b23284388675dcabd7e5e8037fb0;>22a8cfa
 [MNG-6648] 'mavenrc_pre' script does not receive arguments like mavenrc in 
Bo...
   https://github.com/apache/maven/commit/b74199ed446c83282ad806afaf962a7f74eac0ea;>b74199e
 [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports
   https://github.com/apache/maven/commit/c395ca976dc9eaed65dcdc0037508d1edbfb57f3;>c395ca9
 [MNG-7190] add /usr/local/etc/mavenrc to reference documentation
   https://github.com/apache/maven/commit/25df095829bff8a1744db7dbf1ddd14aa1f8d43f;>25df095
 [MNG-7190] Load mavenrc from /usr/local/etc also in Bourne shell script
   https://github.com/apache/maven/commit/268f9565746175f5900670e372092e0c071d85bd;>268f956
 Use proper term: directory
   https://github.com/apache/maven/commit/176b272f30c4fbd62013b4702ab28518c21628ac;>176b272
 [MNG-7185] Describe explicit and recommended version for 
VersionRange.createF...
   Additional commits viewable in https://github.com/apache/maven/compare/maven-3.0.5...maven-3.8.2;>compare
 view
   
   
   
   
   Updates `maven-core` from 3.0.5 to 3.8.2
   
   Commits
   
   https://github.com/apache/maven/commit/ea98e05a04480131370aa0c110b8c54cf726c06f;>ea98e05
 [maven-release-plugin] prepare release maven-3.8.2
   https://github.com/apache/maven/commit/7ecdb3c970d71de3e48fe4de691388868ac03630;>7ecdb3c
 [MNG-7198] Upgrade SLF4J to 1.7.32
   https://github.com/apache/maven/commit/51f6d8b8525d8bf218f70100ec99a7ae97097923;>51f6d8b
 [MNG-7196] Upgrade Jansi to 2.3.4
   https://github.com/apache/maven/commit/f32eb09892686cba083f9f175b3c8eac0ac42ae7;>f32eb09
 [MNG-7010] Omit NB: JAVA_HOME should point to a JDK not a JRE
   https://github.com/apache/maven/commit/22a8cfa05976b23284388675dcabd7e5e8037fb0;>22a8cfa
 [MNG-6648] 'mavenrc_pre' script does not receive arguments like mavenrc in 
Bo...
   https://github.com/apache/maven/commit/b74199ed446c83282ad806afaf962a7f74eac0ea;>b74199e
 [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports
   https://github.com/apache/maven/commit/c395ca976dc9eaed65dcdc0037508d1edbfb57f3;>c395ca9
 [MNG-7190] add /usr/local/etc/mavenrc to reference documentation
   https://github.com/apache/maven/commit/25df095829bff8a1744db7dbf1ddd14aa1f8d43f;>25df095
 [MNG-7190] Load mavenrc from /usr/local/etc also in Bourne shell script
   https://github.com/apache/maven/commit/268f9565746175f5900670e372092e0c071d85bd;>268f956
 Use proper term: directory
   

Re: Request for Enhancement: Dependency Overrides

[Romain Manni-Bucau]

Le dim. 15 août 2021 à 18:19, Enno Thieleke  a
écrit :

> This will most likely be the last answer I'll give you, because I don't
> see any constructive criticism on your part. All you're saying is that it's
> redundant here and not helping there. Although it would help many people a
> great deal and I've showed you.
>
> > It is the definition of an exclude+include. A replacement means A is NO
> more there.
> That's why I said it's logically. The dependency node in the graph is
> still there. It's just not A anymore, but B (i.e. the contents of the node
> have been replaced, not excluded).
>

If you removed a dep from the dep tree you excluded it, nothing to discuss
there, your grammar does not show it but mathematically it is what you did.




> > It is required, you showed it with your log example, will not survive
> time - at least no more than a PoC.
> If by that you mean that you won't find A anymore if you do a
> dependency:tree, then yes. And I said earlier that the output might need to
> be improved.
>

No, i meant it is not maintainable in time to have done it.



> > Look at javax/geronimo/redhat/jakarta deps, this problem is there for
> more than 10 years and your proposal does not change that
> You're right, my proposal doesn't change that nor is meant to. It's meant
> to help you as a developer to write concise POMs that don't suffer from the
> issue/problem you mentioned.
>

So once again you only solve a verbosity issue at the wrong level IMHO.



> > Dep mgt goal is to be global for the subtree, this is not overkill.
> Overrides is since at the end it does the same slightly differently.
> "Slightly differently" is the understatement of the year so far. Writing
> ONE snippet of XML instead the same one repeatedly or worse entire POMs and
> BOMs is not overkill, it's helpful.
>

Once again it is *wrong* as explained to you multiple times with dep mgt or
pivot pom.



> > Once again the natural way is to use dep mgt as documented, what is the
> point of override?
> There's no such thing as a natural way in this case. Dependency management
> has been designed by humans and it can be changed by humans. If we
> constrained ourselves to stuff that's already out there, we wouldn't have
> come far. Please show a bit more open-mindedness in this regard.
>

Natural= the way.
You create another sibling one whichbis bad IMHO.


> > Once you start to use override and you also consume the override where
> do you put it? In both locations?
> The true power of overrides come into play when resolving dependencies
> that are not part your reactor. Applying overrides to dependencies inside
> your reactor is for consistency. I'd also go so far and implement a warning
> that you use an override in your reactor, because those dependencies are
> under your control. The transitive dependencies are not. As a side note: I
> would not want to allow artifacts of your reactor to be used as overrides,
> because that could lead to cyclic dependencies.
>

It is always in your reactor somehow and does not change much the issue.


> > Please use all resolvers not relying on maven deps, they are numerous
> out there.
> Definitely not. This feature is a Maven thing. Maven provides all the code
> that's necessary to resolve artifacts. If somebody (a person or a company)
> reimplements the Maven Resolver, then it's their responsibility to keep up
> with Maven's development.
>

No, you dont like maven style so propose an alternative, be it, but it is
an extension IMHO.



> > We are not gradle and dont want to force all repo to embed our wrapper
> or binaries because we keep breaking ourselves IMHO.
> Amen. Although Gradle has the concept of replacements:
> https://docs.gradle.org/current/userguide/resolution_rules.html#sec:module_replacement
> I appreciate the fact, that the Maven developers try to keep Maven and its
> plugins to be as compatible as possible. But sometimes changes are in
> order. And when a new major version is knocking on your door, why not
> include such changes?
>

Consumed pom version will never change.
Compat of central is what makes it useful, no discussion on it and why i
spoke on consumed pom.



> > Take your bom example. You dont want to override 3-4 deps but a full
> transitive subtree.
> Overriding an entire subtree is a as simple as writing one override - it
> cuts off anything below, because the original has been replaced and
> therefore all its transitive dependencies. If you want to replace specific
> leaves in the graph and many of them, then yes, it'd be verbose. But not
> more than using exclusions.
>


Try it, override an overriden dep comes quickly and you are back to the
original issue so why another way to do the same.


> > The resolution must stay a tree one to be maven compliant so not sure it
> brings anything here again.
> Not gonna lie, I don't understand what you're trying to say.
>

You create a 2 roots tree, it is very hard to maintain in practise.



> > This is well solve using 

Re: Request for Enhancement: Dependency Overrides

[Enno Thieleke]

This will most likely be the last answer I'll give you, because I don't see any 
constructive criticism on your part. All you're saying is that it's redundant 
here and not helping there. Although it would help many people a great deal and 
I've showed you.

> It is the definition of an exclude+include. A replacement means A is NO more 
> there.
That's why I said it's logically. The dependency node in the graph is still 
there. It's just not A anymore, but B (i.e. the contents of the node have been 
replaced, not excluded).

> It is required, you showed it with your log example, will not survive time - 
> at least no more than a PoC.
If by that you mean that you won't find A anymore if you do a dependency:tree, 
then yes. And I said earlier that the output might need to be improved.

> Look at javax/geronimo/redhat/jakarta deps, this problem is there for more 
> than 10 years and your proposal does not change that
You're right, my proposal doesn't change that nor is meant to. It's meant to 
help you as a developer to write concise POMs that don't suffer from the 
issue/problem you mentioned.

> Dep mgt goal is to be global for the subtree, this is not overkill. Overrides 
> is since at the end it does the same slightly differently.
"Slightly differently" is the understatement of the year so far. Writing ONE 
snippet of XML instead the same one repeatedly or worse entire POMs and BOMs is 
not overkill, it's helpful.

> Once again the natural way is to use dep mgt as documented, what is the point 
> of override?
There's no such thing as a natural way in this case. Dependency management has 
been designed by humans and it can be changed by humans. If we constrained 
ourselves to stuff that's already out there, we wouldn't have come far. Please 
show a bit more open-mindedness in this regard.

> Once you start to use override and you also consume the override where do you 
> put it? In both locations?
The true power of overrides come into play when resolving dependencies that are 
not part your reactor. Applying overrides to dependencies inside your reactor 
is for consistency. I'd also go so far and implement a warning that you use an 
override in your reactor, because those dependencies are under your control. 
The transitive dependencies are not. As a side note: I would not want to allow 
artifacts of your reactor to be used as overrides, because that could lead to 
cyclic dependencies.

> Please use all resolvers not relying on maven deps, they are numerous out 
> there.
Definitely not. This feature is a Maven thing. Maven provides all the code 
that's necessary to resolve artifacts. If somebody (a person or a company) 
reimplements the Maven Resolver, then it's their responsibility to keep up with 
Maven's development.

> We are not gradle and dont want to force all repo to embed our wrapper or 
> binaries because we keep breaking ourselves IMHO.
Amen. Although Gradle has the concept of replacements: 
https://docs.gradle.org/current/userguide/resolution_rules.html#sec:module_replacement
I appreciate the fact, that the Maven developers try to keep Maven and its 
plugins to be as compatible as possible. But sometimes changes are in order. 
And when a new major version is knocking on your door, why not include such 
changes?

> Take your bom example. You dont want to override 3-4 deps but a full 
> transitive subtree.
Overriding an entire subtree is a as simple as writing one override - it cuts 
off anything below, because the original has been replaced and therefore all 
its transitive dependencies. If you want to replace specific leaves in the 
graph and many of them, then yes, it'd be verbose. But not more than using 
exclusions.

> The resolution must stay a tree one to be maven compliant so not sure it 
> brings anything here again.
Not gonna lie, I don't understand what you're trying to say.

> This is well solve using dependency plugin and dep/dep mgt sections *already*.
It isn't. It just isn't. Otherwise, people wouldn't be requesting it for years 
now. Are you saying that _all_ of these people don't know how to use Maven? 
They do and they found a weak spot and are suggesting a concept to improve 
Maven.

> So your goal is to bring a shortcut so to work on pom verbosity only as I 
> explained. This is not from where it should be tackled IMHO.
Then bloody come up with a better idea. There's no doubt that there's a gap to 
be filled here and I'm taking action. What will you do?

> Not using dep mgt and/or packaging=pom modules, just give it a try. It is 
> clean, maven aligned and neat at the end.
Not gonna happen. I know that I don't want to maintain many additional POMs. 
Also, I'd have to use different coordinates to resolve, say, Hibernate. I'd 
have to use something like com.mycompany:hibernate-with-jakartaee8-deps:pom. 
And it still wouldn't result in a clean graph since the addition of the correct 
dependencies are in the POM, not in Hibernate (as far as the graph is 
concerned).

As mentioned 

Re: Request for Enhancement: Dependency Overrides

[Romain Manni-Bucau]

Le dim. 15 août 2021 à 14:29, Enno Thieleke  a
écrit :

> An override is not an exclusion - it enforces a replacement. In other
> words: A becomes B, so A is still there, but rather logically than
> physically.
>

It is the definition of an exclude+include. A replacement means A is NO
more there.



> Also, I don't see the need for a dependency:check-overrides mojo. I trust
> in the abilities of developers (until proven otherwise). If someone
> replaced an artifact with an incompatible one, it would be a mistake one
> makes only once, and it's no big deal since people learn all the time.
>

It is required, you showed it with your log example, will not survive time
- at least no more than a PoC.
Look at javax/geronimo/redhat/jakarta deps, this problem is there for more
than 10 years and your proposal does not change that at all so if you
complexify the analyzis, you must tool it way stronger too.



> Concerning your point, that it's overkill to have multiple ways the model
> a dependency graph: I disagree. If that were true, dependency management
> would be overkill entirely, because all that's done by dependency
> management can be done without it - just not in a concise way.
> Maven is all about a strong declarative approach, which is why shortcuts
> are needed. You could model all exclusions and dependencies manually (have
> fun doing that in a huge multi module project), or you could use dependency
> management to help you express something like "whenever A is used, use the
> version X und exclude Z" (the is what one managed dependency could and
> should be read and interpreted as). I merely want to add one thing to this
> management feature: "whenever A is used, use B instead".
>

Dep mgt goal is to be global for the subtree, this is not overkill.
Overrides is since at the end it does the same slightly differently.


> You say that Maven is verbose in general. I agree. But that is totally
> off-topic (although I'd really love to see Maven use XML and utilize
> attributes).
>
> Now to the drawbacks you listed:
>
>   1.  users don't know anymore where to do things
> Oh, but they do. The XML elements are self-explanatory. Exclusions
> exclude, overrides override. If you think that the elements are not
> self-explanatory, then please suggest different names or locations in the
> POM. As mentioned earlier, I provided a PoC, something up for discussion,
> not a final solution.
>

Once again the natural way is to use dep mgt as documented, what is the
point of override?
Once you start to use override and you also consume the override where do
you put it? In both locations?
Just makes a mess for dev IMHO.


  2.  you break most of the tooling related to maven
> My PoC doesn't break any tooling that I'm aware of. Dependency resolution
> works better than before IMO and plugins don't need to be changed - I
> tested it with dependency:tree and help:effective-pom. While the output of
> the latter could be improved, it does show the truth. But again, please
> keep in mind, that we're talking about a PoC for a feature of a new major
> version of Maven and according to semantic versioning, breaking changes are
> allowed when changing the major version.
> Concerning the model version change from 4.0 to 4.1: If that breaks some
> plugin or tooling, then the affected code needs some work anyway.
>


Please use all resolvers not relying on maven deps, they are numerous out
there.
Use coursier for example.
The "they will be updated" - all IDE and plugins and resolvers - is a weak
answer I dont consider as an option.
We are not gradle and dont want to force all repo to embed our wrapper or
binaries because we keep breaking ourselves IMHO.

  3.  it requires profiles to be useful for boms
> I see this as claim at this point, nothing more. Please elaborate and
> provide an example.
>

Take your bom example. You dont want to override 3-4 deps but a full
transitive subtree.
This will be insanely verbose until you can import overrides from another
bom somehow - not inheriting from dep mgt which seems to be your target.
This is what was behind the profile idea.
Also think to conflict resolution there too.
Makes really the pom a mess with dependency management in too much sections.

  4.  it has the exact same pitfalls than current blocks so you will need
> an overrideOverride block in a few months
> Yes, it does have the same pitfalls. These are pitfalls we'll never, ever
> get rid of. Provide a wrong replacement, no matter what mechanism you use
> (exclusions or overrides), and your code won't run. Plain and simple.
> Also, no you wouldn't need an overrideOverride to solve an issue like
> this. You'd just redefine the override in your project or module. The
> "original" artifact is used to identify the override on a per module basis.
> So, defining B to be used instead of A is globally possible, but can be
> replaced with C is to be used instead of A in a different POM. At least
> this is how I intend it to work.
>

The 

Re: Request for Enhancement: Dependency Overrides

[Enno Thieleke]

An override is not an exclusion - it enforces a replacement. In other words: A 
becomes B, so A is still there, but rather logically than physically.

Also, I don't see the need for a dependency:check-overrides mojo. I trust in 
the abilities of developers (until proven otherwise). If someone replaced an 
artifact with an incompatible one, it would be a mistake one makes only once, 
and it's no big deal since people learn all the time.

Concerning your point, that it's overkill to have multiple ways the model a 
dependency graph: I disagree. If that were true, dependency management would be 
overkill entirely, because all that's done by dependency management can be done 
without it - just not in a concise way.
Maven is all about a strong declarative approach, which is why shortcuts are 
needed. You could model all exclusions and dependencies manually (have fun 
doing that in a huge multi module project), or you could use dependency 
management to help you express something like "whenever A is used, use the 
version X und exclude Z" (the is what one managed dependency could and should 
be read and interpreted as). I merely want to add one thing to this management 
feature: "whenever A is used, use B instead".

You say that Maven is verbose in general. I agree. But that is totally 
off-topic (although I'd really love to see Maven use XML and utilize 
attributes).

Now to the drawbacks you listed:

  1.  users don't know anymore where to do things
Oh, but they do. The XML elements are self-explanatory. Exclusions exclude, 
overrides override. If you think that the elements are not self-explanatory, 
then please suggest different names or locations in the POM. As mentioned 
earlier, I provided a PoC, something up for discussion, not a final solution.
  2.  you break most of the tooling related to maven
My PoC doesn't break any tooling that I'm aware of. Dependency resolution works 
better than before IMO and plugins don't need to be changed - I tested it with 
dependency:tree and help:effective-pom. While the output of the latter could be 
improved, it does show the truth. But again, please keep in mind, that we're 
talking about a PoC for a feature of a new major version of Maven and according 
to semantic versioning, breaking changes are allowed when changing the major 
version.
Concerning the model version change from 4.0 to 4.1: If that breaks some plugin 
or tooling, then the affected code needs some work anyway.
  3.  it requires profiles to be useful for boms
I see this as claim at this point, nothing more. Please elaborate and provide 
an example.
  4.  it has the exact same pitfalls than current blocks so you will need an 
overrideOverride block in a few months
Yes, it does have the same pitfalls. These are pitfalls we'll never, ever get 
rid of. Provide a wrong replacement, no matter what mechanism you use 
(exclusions or overrides), and your code won't run. Plain and simple.
Also, no you wouldn't need an overrideOverride to solve an issue like this. 
You'd just redefine the override in your project or module. The "original" 
artifact is used to identify the override on a per module basis. So, defining B 
to be used instead of A is globally possible, but can be replaced with C is to 
be used instead of A in a different POM. At least this is how I intend it to 
work.
  5.  does not solve the broken BOM definitions which seems to be where your 
issue is coming from
My motivation is not coming from "broken" BOM definitions alone. If I wasn't 
using BOMs at all, I'd still face the issue of having to clean up my dependency 
graphs. Also, ask yourself why those BOMs are "broken" in the first place: it's 
because there's no shortcut to clean up the mess, yet.
My motivation also comes from the fact that I don't want to repeat myself over 
and over again, which I what must do if I use exclusions.


From: Romain Manni-Bucau 
Sent: Sunday, August 15, 2021 8:35 AM
To: Maven Developers List 
Subject: Re: Request for Enhancement: Dependency Overrides

Le sam. 14 août 2021 à 22:21, Enno Thieleke  a
écrit :

> Ok, I feel like we're turning in circles here.
>
> If the feature I'm proposing exists already (without excludes and without
> the need for extra POMs and BOMs, i.e. the common solution), please post a
> link to the docs. If it doesn't exist and people ask for it [1] (and have
> been for years), then I don't see why you'd want to reject it.
>

It requires excludes, as your proposal does (since to override a jar you
need to list the excluded one, this is literally an exclude even if you
name differently the tag).
Since it can be done globally in the dep mgt it is exactly what you request
except you control your dependencies whereas you want to apply rules
without knowing if they are useful so it means you will need to add a
dependency:check-overrides mojo just for that purpose and users to run it
which is overkill as having 2 ways to do the same thing IMHO.


>
> The common 

[GitHub] [maven-site] michael-o merged pull request #253: Document known issues

[GitBox]

michael-o merged pull request #253:
URL: https://github.com/apache/maven-site/pull/253


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

AW: Request for Enhancement: Dependency Overrides

[Christofer Dutz]

Coming a bit late to the party ... I think this is something I had been 
requesting every 1-2 years for some time.
As during my time as a consultant migrations to Maven I keept running into this 
problem. Here I usually had the task of streamlining the dependency usage of 
many teams so their end-products worked together nicely. 

Here I had a lot of problems like: Someone using a fat-jar instead of a normal 
jar. Someone using wrong coordinates (third party release of something and not 
using the official one). DepgendencyManagement exclusions helped getting rid of 
these, but we needed to find out which modules relied on them and had to add 
dependencies to each module manually. In the worst case I had to communicate 
with the team-leads of 200 development teams for them to update their poms (And 
I guess everyone working in banks knows: One does not simply commit to a repo 
that's not your team's repo). I think I asked for dependencyManagement to add 
an "inclusions" element to the "exclusions" ... perhaps that would be something 
worth considering?

But all in all ... I'm totally +1 for a feature like that.

Chris

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau  
Gesendet: Sonntag, 15. August 2021 08:36
An: Maven Developers List 
Betreff: Re: Request for Enhancement: Dependency Overrides

Le sam. 14 août 2021 à 22:21, Enno Thieleke  a 
écrit :

> Ok, I feel like we're turning in circles here.
>
> If the feature I'm proposing exists already (without excludes and 
> without the need for extra POMs and BOMs, i.e. the common solution), 
> please post a link to the docs. If it doesn't exist and people ask for 
> it [1] (and have been for years), then I don't see why you'd want to reject 
> it.
>

It requires excludes, as your proposal does (since to override a jar you need 
to list the excluded one, this is literally an exclude even if you name 
differently the tag).
Since it can be done globally in the dep mgt it is exactly what you request 
except you control your dependencies whereas you want to apply rules without 
knowing if they are useful so it means you will need to add a 
dependency:check-overrides mojo just for that purpose and users to run it which 
is overkill as having 2 ways to do the same thing IMHO.


>
> The common solution is cumbersome and verbose. Why somebody would 
> prefer it over a more concise XML element is beyond me.
>

It is not really and, once again, most of maven definition can be seen as 
verbose - but here it is the same as your proposal.
If you want to tackle verbosity it is another topic whith way more items than 
this one (the artifact definition likely being inlining as a first item).


>
> You say it brings drawbacks. What are they? Please elaborate.
>

The one I listed:

1. you duplicate the definition so the pom reading is less straight forward + 
users don't know anymore where to do things 2. you break most of the tooling 
related to maven and must drop this section in the pom producer (so you dont 
solve the verbosity issue for
consumer)
3. it requires profiles to be useful for boms (not  but 
jakarta for ex) 4. it has the exact same pitfalls than 
current blocks so you will need an overrideOverride block in a few months 5. 
does not solve the broken BOM definitions which seems to be where your issue is 
coming from



>
> [1]
> https://issues.apache.org/jira/browse/MNG-4530
> https://issues.apache.org/jira/browse/MNG-5652
> https://issues.apache.org/jira/browse/MNG-1977
> 
> 
> From: Romain Manni-Bucau 
> Sent: Saturday, August 14, 2021 8:14 PM
> To: Maven Developers List 
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Le sam. 14 août 2021 à 18:56, Enno Thieleke 
>  a écrit :
>
> > You're right. Currently, if I want to control my dependencies, I 
> > must resort to excludes and define the dependencies I really want 
> > myself. And putting something like that in one or two POMs and 
> > aggregating them in a BOM is very dirty in my opinion. Not only is 
> > it noisy/verbose when it
> comes
> > to writing XML, it also adds nodes to the dependency graph where 
> > they shouldn't be - not to mention unnecessary indirections.
> > The need for overrides is becoming bigger and bigger. As the Maven 
> > ecosystem grows, artifacts with practically the same content but 
> > with different coordinates are becoming more frequent.
> >
>
> I disagree, your solution is 1-1 with existing one, just somewhere 
> else which is one pitfall as mentionned.
> It is also not new and solved since at least ten years so not sure 
> what is specific for you here and what makes the common solution less 
> practical or verbose.
>
>
>
> > Whether my proposal is about rewriting a POM dynamically is unclear 
> > at this point. I came here to propose the feature of overrides and 
> > provided
> a
> > simple PoC, not the final solution. What I consider to be clear at 
> > this point is that 

[NOTICE] - Moving and Upgrading of Buildbot Jobs

[Gavin McDonald]

Hi All.

This NOTICE goes out via BCC to all affected projects and to the
main bui...@apache.org mailing list.
Please have replies CC the builds list.

https://ci.apache.org is currently on version 0.8 and is to be turned off
soon.
https://ci2.apache.org is version 3.2 and is the direct replacement.

If you project has Buildbot jobs they are listed here:

https://cwiki.apache.org/confluence/display/INFRA/Buildbot+0.8+-%3E+3.2+Migration

Infra will perform the migration for you over the next 2 weeks. Starting
Monday.

Your $project.conf code will be updated to be compatible with Buildbot 3.2
(from 0.8)

Unless you state otherwise - your config will be moved to a new SVN [1] or
GIT [2] area
depending on whether you primarily use SVN or GIT.

[1] - https://svn.apache.org/repos/infra/infrastructure/buildbot2
[2] - https://github.com/apache/infrastructure-bb2

An INFRA ticket will be created for each project migration and your dev
list will be kept in the loop.

For those of you with nightly builds that use ci.apache.org/projects/* -
please note that this service is deprecated and will NOT be available going
forward. Instead, your jobs should be changed to upload to
https://nightlies.apache.org/$project/* instead. Please request if you want
your existing content migrated over otherwise we will not do so.

After migration: Once everybody is off of the old Buildbot 0.8 - we will
change ci.apache.org to point to the new 3.2 instance. We will also put in
a redirect for ci.apache.org/projects/$project/* to point to your new
location at nightlies.apache.org/$project/*

Please let us know if you have any questions. Either Drew Foulks or myself
will perform your migration.

Kind Regards.

-- 

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team

Re: Request for Enhancement: Dependency Overrides

[Romain Manni-Bucau]

Le sam. 14 août 2021 à 22:21, Enno Thieleke  a
écrit :

> Ok, I feel like we're turning in circles here.
>
> If the feature I'm proposing exists already (without excludes and without
> the need for extra POMs and BOMs, i.e. the common solution), please post a
> link to the docs. If it doesn't exist and people ask for it [1] (and have
> been for years), then I don't see why you'd want to reject it.
>

It requires excludes, as your proposal does (since to override a jar you
need to list the excluded one, this is literally an exclude even if you
name differently the tag).
Since it can be done globally in the dep mgt it is exactly what you request
except you control your dependencies whereas you want to apply rules
without knowing if they are useful so it means you will need to add a
dependency:check-overrides mojo just for that purpose and users to run it
which is overkill as having 2 ways to do the same thing IMHO.


>
> The common solution is cumbersome and verbose. Why somebody would prefer
> it over a more concise XML element is beyond me.
>

It is not really and, once again, most of maven definition can be seen as
verbose - but here it is the same as your proposal.
If you want to tackle verbosity it is another topic whith way more items
than this one (the artifact definition likely being inlining as a first
item).


>
> You say it brings drawbacks. What are they? Please elaborate.
>

The one I listed:

1. you duplicate the definition so the pom reading is less straight
forward + users don't know anymore where to do things
2. you break most of the tooling related to maven and must drop this
section in the pom producer (so you dont solve the verbosity issue for
consumer)
3. it requires profiles to be useful for boms (not  but
jakarta for ex)
4. it has the exact same pitfalls than current blocks so you will need an
overrideOverride block in a few months
5. does not solve the broken BOM definitions which seems to be where your
issue is coming from



>
> [1]
> https://issues.apache.org/jira/browse/MNG-4530
> https://issues.apache.org/jira/browse/MNG-5652
> https://issues.apache.org/jira/browse/MNG-1977
> 
> 
> From: Romain Manni-Bucau 
> Sent: Saturday, August 14, 2021 8:14 PM
> To: Maven Developers List 
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Le sam. 14 août 2021 à 18:56, Enno Thieleke 
> a
> écrit :
>
> > You're right. Currently, if I want to control my dependencies, I must
> > resort to excludes and define the dependencies I really want myself. And
> > putting something like that in one or two POMs and aggregating them in a
> > BOM is very dirty in my opinion. Not only is it noisy/verbose when it
> comes
> > to writing XML, it also adds nodes to the dependency graph where they
> > shouldn't be - not to mention unnecessary indirections.
> > The need for overrides is becoming bigger and bigger. As the Maven
> > ecosystem grows, artifacts with practically the same content but with
> > different coordinates are becoming more frequent.
> >
>
> I disagree, your solution is 1-1 with existing one, just somewhere else
> which is one pitfall as mentionned.
> It is also not new and solved since at least ten years so not sure what is
> specific for you here and what makes the common solution less practical or
> verbose.
>
>
>
> > Whether my proposal is about rewriting a POM dynamically is unclear at
> > this point. I came here to propose the feature of overrides and provided
> a
> > simple PoC, not the final solution. What I consider to be clear at this
> > point is that overrides need to exist in Maven as a core feature, not as
> an
> > extension, because this way the Maven Resolver can be changed as well to
> > honor the feature which would enable overrides to work transitively (all
> > part of the PoC).
> >
>
> It is already there, definition is deterministic and fully defined.
> Verbosity is a thing but then you want g:a:v definition too if you want to
> tackle it so I assume it is out of topic.
>
>
>
> > To your point: Yes, you can do all the stuff we're talking about today
> > already. Just not in a convenient way with a clean result - the effective
> > result is just "good enough".
>
>
> Once again, 1-1 with your proposal as of today since you just meta define
> deps in it.
>
>
> This brings me back to writing POMs and BOMs for "overriding" dependencies.
> > That's a lot of work. If one snippet of XML - a different grammar - does
> > all that, then I'd gladly take it.
> >
>
> Isnt it xlst ;), can be another way to impl it with mvn 4 but still not a
> core feature IMHO. Brings more drawbacks and no new feature.
>
> 
> > From: Romain Manni-Bucau 
> > Sent: Saturday, August 14, 2021 5:08 PM
> > To: Maven Developers List 
> > Subject: Re: Request for Enhancement: Dependency Overrides
> >
> > Le sam. 14 août 2021 à 16:52, Enno Thieleke  >
> > a
> > écrit :
> >
> > > You are