Hi, there are a few things in this thread:
1. commons-compress 2 must not be compatible with v1 by commons rule (did we miss it? the rule is to change the package to "2") 2. in your pom you can always exclude from a dep a transitive dep and enforce it explicitly 3. if 2 is bothering the common trick is to do a module with packaging=pom doing the exclude+explicit dep and use this instead of the 3rd party everywhere in your project (common if you have > 1 module in your project using it) 4. assuming 1 is not respected for whatever reason you can use 2 and 3 to solve the switch easily and maven enforcer or any other plugin to prevent the usage of v1 (or v2 aggregator module) anywhere so from my window you are covered for all use cases Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le dim. 12 oct. 2025 à 15:40, Vladimir Sitnikov <[email protected]> a écrit : > 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 >
