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]
