> > > Just one question: Why? > > > > The implementation jars for compress would be tiny and would have close > to > > 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 https://github.com/apache/commons-compress/blob/master/pom.xml#L69 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 allows), 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.
