Vladimir, Sorry, but it is hard for me to follow you. From what you said, I guess my conclusions below are correct: * commons-compress 1.0 and modularized commons-compress-* 2.0 are binary compatible (given you assume they are interchangeable) * commons-compress-foo 2.0 allows for "modular" (only foo) access (it pulls in commons-compress-core 2.0 "shared" code)
So let me ask this: what classes are expected to reside in commons-compress 2.0? Or in other word, how do you guarantee binary compatibility without those classes present, if the user uses commons-compress-tar 2.0 (+ commons-compress-core 2.0)? On Sun, Oct 12, 2025 at 12:59 PM Vladimir Sitnikov <[email protected]> wrote: > > >but your original example _again_ had something like this: > - it depends on commons-compress 1.0 > - it depends on commons-compress-tar 2.0 > > >So what now? What do you expect here: > - full commons-compress features? (as you depend on commons-compress) > -- if so, 1.0 or 2.0? > - only tar features? (as you depend on commons-compress-tar 2.0) what > about the previous stanza? > > Commons-compress means full features should be there. There’ tar 2.0.0, so > all the features should be 2.0.0. > > Of course, as long as the application has commons-compress it does not get > all benefits of commons-compress modularity. However, the developer could > manually exclude xz-2.0.0 if they know the jar is not needed. They could > even do rm xz-2.0.0.jar when patching prod systems. > > It is an important case for the ecosystem to transition to v2: one library > might still use 1.0.0 while the other might depend on a submodule of 2.0.0. > It is important to keep that mix runnable without extra configuration from > the app developer. > > >What happens if commons-compress-core depends on commons-compress and > EXCLUDES all (*) of its dependencies? > > I haven’t tried it, however, having commons-compress-core to include > <dependencyManagement>…commons-compress:2.0.0 sounds like a cleaner way to > convey the meaning than making commons-compress-core to depend on > commons-compress and exclude its transitives. > > There might be an edge case if commons-compressed:2.0.0 jar has classes. > Then “depend on it and exclude transitives” would still end up with > commons-compress-2.0.0.jar > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
