>yes, I had also to "tweak" the project: >(commons-compress-core:2.0.0 depends on commons-compress:2,0.0)
Tamás, unfortunately, the "tweak" defeats the purpose of modularization. The purpose of the split is to enable users to get only the needed bits from the library. In other words, if a library wants only tar compression, it should not receive all the other compressors automatically. Here's a concrete example: v1 world: if a user depends on commons-compress:1.0.0, they get all the compressors, and they get all the CVEs at the same time. This is the current case with Apache Commons Compress. Everything is in a single jar. v2 world (something which would be way better that v1): commons-compress-tar:2.0.0: only the classes needed for TAR commons-compress-xz:2.0.0: only the classes needed for XZ commons-compress-core:2.0.0 only the core classes (e.g. needed by TAR and XZ compressors) commons-compress:2.0.0: a fallback artifact that depends on both commons-compress-tar and commons-compress-xz so the projects that previously used commons-compress would continue to work just fine. If you suggest adding commons-compress-core -> commons-compress dependency, then it would effectively mean everyone who depends on "just" commons-compress-tar would transitively get everything through commons-compress-core:2.0.0 -> commons-compress:2.0.0 -> every jar Could you please reconsider so it would be possible to depend on a subset of the commons-compress jars to minimize the attack surface? Vladimir
