Tamás, Having both "commons-compress 2.0.0 depends on commons-compress-core 2.0.0" (is is required for backward compatibility) and "commons-compress-core 2.0.0 depends on commons-compress 2.0.0 with exclusions" (it is the suggested workaround) creates a dependency cycle, which looks like a blocker issue on its own.
Both Maven and Gradle forbid cyclic dependencies between modules, so the suggested workaround (adding commons-compress-core -> commons-compress) is not workable. (I realized that only as I tried adding the dependency to my build scripts and got the cyclic dependency failure) > commons-compress 1.0 and modularized commons-compress-* 2.0 are >binary compatible (given you assume they are interchangeable) +1. A slight comment: 2.0 might contain more APIs, however, all (or almost all) 1.0 APIs should be present in 2.0. So it should be fine to exchange 1.0 with 2.0, however if someone tries to replace 2.0 with 1.0, it could cause errors. >* commons-compress-foo 2.0 allows for "modular" (only foo) access (it >pulls in commons-compress-core 2.0 "shared" code) +1 >what classes are expected to reside in commons-compress 2.0? I think it should be empty. Having no classes at the commons-compress-2.0.0 would be easier to reason. >if the user uses commons-compress-tar 2.0 (+ >commons-compress-core 2.0)? If the user has migrated to commons-compress-tar 2.0, it means they use only a subset of the classes, so they do not need the full set of old commons-compress 1.0. Vladimir
