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