> > > 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.
