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.
Including the source is simpler and avoids these issues.
That said, the picocli binary artifacts are available from Maven Nexus and Bintray.
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.
Why not support a more modern version of Java, like Java 8?
-
Using Java 5 allows more people to use picocli. There are many (mostly corporate) environments with systems that are stuck on older versions of Java. There may not be many users in this situation, but I see no reason to exclude them.
-
Java 5 has all the facilities that are needed. I agree that using a later version of Java would make maintenance and development more convenient for me and for contributors, but that is a trade-off I’m willing to take. For example, I would love to be able to use default methods on interfaces for API evolution, instead of the more clumsy-looking
IExceptionHandler2, but I don’t consider this a compelling reason to start requiring Java 8 from picocli users.
That said, my position may change. For example, if build tools or quality assurance tools come up that provide compelling value but require the project to use a later version of Java, I may reconsider. For example, annotation processing being integrated in javac from Java 6 is why the picocli-codegen module will require Java 6 from picocli 4.0, and the google/compile-testing library is why the picocli-annotation-processing-tests module requires Java 8.