Thanks for the pointers, I missed it indeed. However, it looks like JLBP-6 is a Maven-specific issue. I've crafted a sample project [1] that splits the jar, and it turns out Maven (both 3.9.11 and 4.0.0-rc-4) does not seem to honor `<dependencyManagement>` from `commons-compress-core` which is somewhat surprising to me.
Gradle is not affected by JLBP-6's "Case 2: Rename Maven ID", and it honors transitive BOMs, so it bumps commons-compress from 1.0.0 to 2.0.0 as soon as it observes commons-compress-core:2.0.0 on the classpath. Do you know if it was something considered to be fixed at Maven side? The logic is as follows: commons-compress-core:2.0.0 refers to commons-compress:2.0.0 BOM, thus it is reasonable to consider the BOM as a part of the resolution. Why ignore the BOM? Frankly, it sounds sad the ecosystem has to rename both packages and artifacts causing significant disruption which should better be solved at the Maven side. Of course, going with redesign of the API is a different story. Making an explicit compress2-api module does sound fair for changing the packages and artifact names. However, it is sad Maven can't handle splitting the jar in two. I've found [2], which is "closed, fixed in 4.0.0"; however, my tests show Maven 4.0.0-rc-4 does not resolve the issue. Either I'm testing it incorrectly, or the issue is not fixed in Maven 4.0. I assume it is reasonable to expect Maven to select commons-compress:2.0.0 in this case. Is there a reason BOMs are only applied when explicitly imported by the direct consumer? I’m happy to constrain any Commons Compress modularization to 2.x with a package rename, however, it would be nice to get it sooner than later. At the end of the day, the consumers do not really need fancy API-SPI. They only need "tar compression" which is free from CVEs in say LHA. [1] https://github.com/vlsi/jarsplit [2] https://issues.apache.org/jira/browse/MNG-5761 Vladimir
