>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
