Re: [compress] High Level API for Archives
> > Just one question: Why?
> > The implementation jars for compress would be tiny and would have close
> > none dependencies.
> As an end user, I'd prefer to only have to manage a single maven coordinate
> (e.g., commons-vfs-ssh) instead of multiple ones depending on my use case
> (i.e., optional dependencies). It makes it easier to figure out which
> solutions are actually supported at a glance without having to dig through
> documentation as well.
> Also, I feel like one of Commons' goals is to avoid jar hell, and providing
> a monolith with several optional dependencies smells like jar hell to me.
That smell must be something else ;)
Just have a look at the dependencies
commons vfs and compress are very different beasts.
I think the idea is to strike a balance between over-modularization
(which is actually quite common in the maven universe) and monoliths.
Both extremes are not great.
That said - optional dependencies are also not really my favorite thing.
I am myself a big fan of shading dependencies in libraries (if the license
which also forces one to re-evaluate the modularity vs inclusiveness of
(even transitive) dependencies.
Having all those separate jars with maybe 5 classes without dependencies
does not make that much sense to me.
Neither from a dependency nor from bytes-on-disk POV.