4

I wrote a utils library (5 KLOC) that a lot of my projects use. I've also written a very small project (150 LOC) that needs just 1 or 2 of the classes in the utils library.

I really don't want to add such a large dependency for such a small use, but the other options...moving/copying the classes or having a utils2 library (yuck!) don't appeal either.

  • 1
    Why not just break your util library into smaller, more atomic, components? – MetaFight Dec 31 '16 at 4:27
  • It only needs 1 or 2 classes, it would help for sure though – Nathan Adams Dec 31 '16 at 4:46
  • 1
    What's the actual disadvantage of using the large library? In languages with a static linker, the linker should omit unused code. – Jerry101 Dec 31 '16 at 4:50
  • 8
    5KLOC is still a tiny library (compare it with Qt which has 18MLOC) so you should basically avoid caring about using all of it. – Basile Starynkevitch Dec 31 '16 at 9:20
  • 2
    Unless you're working in a size-constrained environment, there's little reason to worry about this. You're probably only using a small fraction of your language's standard library, and those tend to be pretty massive. – Blrfl Jan 1 '17 at 12:21
5

The options are:

  1. break your larger utility library in smaller libraries
  2. use a larger library everywhere

There are pros and cons to each approach.

With 1., you end up having eventually a smaller effective installed component but you increase the level of coordination and you need more work and ceremony: for each library you may need a new repository, a new component descriptor (in your case a new POM), a new README or documentation, a new setup for tests and continuous integration, a new versioning and release cycle. So you may end up having less code redistributed but at the cost of more boilerplate. But this approach is rational from a pure engineering standpoint.

With 2., you have eventually a larger effective installed component but you did not duplicate the boilerplate and did not do extra work. This is a pragmatic approach.

In many cases, the extra red tape from option 1. is not worth it and in some communities it reaches absurd levels: there are many node.js packages that end up containing more boilerplate, doc, manifests, etc. than actual JavaScript code.

With 1., if you have a highly automated workflow, the extra costs may seem minimal to you and if you are the only user of this code this may work OK. But when you work as a team and the utilities are reused and maintained by several other, you increase the coordination costs for every user by introducing a new component.

There are other ways though where you could have the best of both and limit the duplication of boilerplate and efforts:

  1. You could keep a single repo and limit the boilerplate by having multiple components descriptors for each sub-library to build: for instance you could keep a single code tree but have multiple POMs (but since POMs beg to be named pom.xml this may not be practical in your special case). Or you could have a single POM and build two Jars from it.

  2. You could adjust the build of your 150 LOC client to extract only the subset of classes you effectively use from this utility library and vendor/re-bundle them in the built Jar (possibly using something like Maven Shade).

Personally, I tend to prefer keeping things simple and keep a single larger utility library. Yet, I may start to break things up in smaller components when there is a clear and well defined subset that ends up being reused individually by at least three other components. I would not bother just for a single usage.

1

To the deployment, you can make build files that compiles only segments of your library. I made an ant build file that accomplish that by recieving a filter of packages and classes to include in the result and a location to drop the generated jar. In my case is Java specific, but this should be doable in many languages. It is more or less what a static c or c++ compilation do it. Not every code goes into the executable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.