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 19:00:15 GMT
>
> > 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.
> >
>
> 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.

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