Il still failling to see any case you cant handlebar from your pom, we do since ages that but without magic
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, 11:21, Tamás Cservenák <[email protected]> a écrit : > 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] > >
