Howdy, sure, 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? - mixed? For example: What happens if commons-compress-core depends on commons-compress and EXCLUDES all (*) of its dependencies? If you updated your example (and I think you did) sorry, am not at desk right now, will take a peek again. T On Sun, Oct 12, 2025 at 11:05 AM Vladimir Sitnikov <[email protected]> wrote: > > >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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
