Re: [compress] High Level API for Archives
> > That said - optional dependencies are also not really my favorite thing.
> > I am myself a big fan of shading dependencies in libraries (if the
> > allows),
> > 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.
Sorry, but I fail to follow your argument here - but that's OK.
I guess we disagree anyway so there is no need to follow up on that.
> 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).
I never used Spring Boot - but you make it sound horrible :)
Popular does not necessarily mean things are a good idea.
Just because Spring decided to maintain a ton of artifacts does not make it
a valid case for it.
Having a simpler dependency tree often outweighs the overhead of a few
extra classes for me.