Re: [compress] High Level API for Archives
On 1 May 2018 at 12:23, Torsten Curdt <tcurdt@xxxxxxxxx> wrote:
> That smell must be something else ;)
> Just have a look at the dependencies
Right, I see several dependencies marked "optional" which means as an end
user, I still have to specify those particular dependencies (which also
means hunting down the correct compatible version if applicable). In a
modular sense, I'd be able to just use the commons-compress-foo dependency
and get third party dependencies transitively.
> 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.
Agreed. One potential splitting point could be by third party dependencies.
Anything that works without them makes sense in a core type module.
> 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.
I'm generally not a fan of shading, even when it makes sense to do so. Then
again, it doesn't seem like many Java developers like the alternatives
anyways (e.g., OSGi), so it's a necessary evil. In fact, one of the more
legitimate uses of it that I can think of is to shade in parts of Apache
Commons libraries so you don't need to depend on the entire library but can
still receive updates.
> 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.
This doesn't seem to be a big deal in practice. If it were, I don't think
Spring Boot would be successful at all (tons of Spring Boot dependencies
are tiny jars with just some json metadata or pom.xml file).
Matt Sicker <boards@xxxxxxxxx>