On 1 May 2018 at 12:23, Torsten Curdt <tcu...@vafer.org> wrote: > That smell must be something else ;) > Just have a look at the dependencies > > https://github.com/apache/commons-compress/blob/master/pom.xml#L69
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 > 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. > 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 <boa...@gmail.com>
