How often have you chosen to write code to parse command line arguments instead of using a library because you didn’t want to burden your users with the extra dependency?
A library can be a great help, but it won’t make your users happy when they get a command line application and in order to run it they need to download and specify another jar file, especially when the only purpose of this library is to make life easier for the application author. End users need to do extra work to save the author some time? Not nice.
"Include as source (it’s only one file)" is one way to solve that problem. It is easy to understand, easy to do, and it doesn’t require any special tooling.
That is another way to solve the problem. It requires some tooling, but it can certainly work. You have somewhat less visibility on what actually goes into the uberjar, and there are some times when shading can cause issues, but that’s usually when more libraries are combined.
However, including the source is simpler and avoids these issues.
Good point. There is always a trade-off. In this case, the trade-off is that it makes my work as a maintainer slightly harder, but makes things easier for the end user. That’s a good trade-off in my book.
Under the hood there are actually quite a few inner classes and interfaces, so it’s not as bad as you would think. The IDE does a good job here. We’ll see if it becomes a problem down the road, but if it does, it’ll be my problem and not the end user’s.
Please see the picocli vs JCommander page for a detailed comparison.
Please see the CLI comparison page for a detailed comparison.
