>This assumes that the new version is backward compatible with older one,
>which in common case is not correct. Especially the mentioned Guava :)

Sergey, there's no such assumption.
Please clarify the exact case when you think my proposal breaks users'
projects.

>users who will have breaking behavior on the Maven update

Please clarify the exact breakages you envision.

>If I have lib-a and lib-b depending on the same library of different
>versions, I want to declare the exact version in my project

Sure you can declare every possible transitive dependency in your root
pom.xml.
However, it would be wasteful practice for many simple projects.

So far it sounds like you say you are used to Maven quirks, and you provide
no
cases when my suggestion would break your or somebody else's workflow.

>1. Don't split libraries
>Many libraries like apache httpclient
>suffer from it as they are quite senstive to matching httpcore, httpclient
>and httpasyncclient

Sergey, it is exactly the issue I mention: automatic alignment is needed.
With my proposal, apache httpclient authors would have a way to
configure poms in such a way so httpcore, httpclient align to the same (or
whatever workable) versions.

>2. Use shade plugin instead of transitive dependencies that may break

Shade plugin does not help for httpclient/log4j/guava/.. cases.
Sure it is helpful sometimes, however, it is unreasonable to go with
shading by default.

>3. Create built-in self-validation of the classpath in your library

It does not solve the issue I highlight.
Please execute the reproducer and suggest how "self-validation" would fix
the runtime failure.

>4. If you really want to make a breaking change like new artifactId,

It does not solve the issue I highlight.
Please execute the reproducer. It makes zero breaking changes.

>5. Use maven-enforcer-plugin in your projects (not libraries)

It does not solve the issue I highlight.
I do not see how maven-enforcer fixes the runtime faliure.

>7. Have you considered maven "<distributionManagement><relocation>" pom

Relocation is a different thing, and it does not solve the issue.

Vladimir

Reply via email to