commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@vafer.org>
Subject Re: [compress] High Level API for Archives
Date Tue, 01 May 2018 17:23:04 GMT
>
> > 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message