Think you want a dependency:fix-broken-pom goal you run manually or/and on a CI but it is not maven role to do dev work, maybe IA one more than a default feature breaking projects by design.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le sam. 11 oct. 2025, 00:12, Tamás Cservenák <[email protected]> a écrit : > Hi Piotr, > > I understand what you wrote. > > What I don't understand is the "demo" project, that does not transitively > depends, but directly depends. > > T > > On Sat, Oct 11, 2025, 00:09 Piotr P. Karwasz <[email protected]> > wrote: > > > Hi Tamas, > > > > On 10.10.2025 23:37, Tamás Cservenák wrote: > > > For me the "goal to solve" is unclear: what is the problem that is to > be > > solved? > > > > The original goal is to split Commons Compress into new artifacts [1] > > *without* renaming packages (i.e., avoid breaking changes), while > > preventing classpath conflicts. > > > > Concretely, an application could transitively depend on both: > > - `commons-compress-core` 2.x via dependency A, and > > - `commons-compress` 1.x via dependency B. > > > > If both artifacts contain classes in the same packages, we get classpath > > hell. > > > > Gradle can effectively propagate BOMs through Gradle Module Metadata > > alignment [2]. If `commons-compress-core` declares > > `commons-compress-bom` in its dependency management, Gradle will import > > that BOM and can “lift” `commons-compress` to the 2.x line (which could > > be an empty JAR), eliminating the conflict. > > > > This approach is inherently iterative (resolve, update dependency > > management, resolve, …), and convergence is not guaranteed in general. > > > > However, automatic alignment is very useful in practice. For example, it > > can keep a project’s Log4j modules consistent even without an explicit > > `log4j-bom` import. This will matter even more going forward: with Log4j > > Core 3 the line splits: `log4j-core` and its extensions move to 3.x, > > while `log4j-api` and the bridges remain on 2.x, so naïve version > > alignment will not work. > > > > Piotr > > > > [1] https://lists.apache.org/thread/47w1t3zk4bo0821zq4bffq8x63bwb7jo > > [2] https://blog.gradle.org/alignment-with-gradle-module-metadata > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
