Le jeu. 6 nov. 2025 à 12:38, Vladimir Sitnikov <[email protected]> a écrit :
> >Just from the emails, without looking at the examples, that's how it > sounds > > Would you recommend anything I could do better? > > >It seems like you want Maven to break one of its principles to support a > >fringe use case. Do you agree? > > I do not. Sure I'm open to reconsider if you clarify the principle you > mean. > I do not see which "principle" my proposal breaks. > I consider the issue like "Maven misses a principle". > > >fringe use case > > Multi-module libraries are quite common, and having a solution for > automatic version alignment is a popular demand. > > Log4j: https://lists.apache.org/thread/z5vqbh75nsl03sy26xtrxh3fwv1h2kn7 > Guava: https://github.com/google/guava/issues/8079#issuecomment-3492464905 > Jackson, JUnit: > https://blog.gradle.org/alignment-with-gradle-module-metadata Should I open a thread "this is totally broken"? :) Joke apart this got explained multiple times too but this breaks projects as soon as the tree is not consistent and when it is consistent it is pointless so it covers a small case - maybe yours but breaks way more than it helps in real life - in particular cause there is literally no issue to make all these niche cases working as Tamas and I showed you. This is not magic? We'll that's life at some point otherwise we wouldn't need releases in any lib. So to highlight one thing of your link: *With Gradle Module Metadata, platform dependencies are published for an automatic updated of the platform (jackson-bom) to the highest selected version.* this is agreat way to break some projects and can't be desired by default as a competiting resolution, we must keep a single mainstream resolution for the ecosystem - which is monstreous - consistence. it is fine to add custom ones for final applications - if it helps you - when they are not consumed by other artifacts outside their own reactor. > > > Vladimir >
