apache
New sources for defining CLI options via a configuration file.
Enable definition of command line arguments via configuration files. This reduces a lot of the code required to create CLI options. Javadoc and unit tests (100% coverage) updated, starting point for reading how to use configuration files is the class CommandLineConfiguration once the javadoc has been built. Developers are required to implement OptionListener in order to get updates.
Coverage increased (+0.9%) to 97.299% when pulling a56dfddc06ac2c982ce1e9237446e5b798390448 on zendawg:cli-configuration into 64900674a1d10f51ca9ef61423d6695be17d8c33 on apache:master.
Hi @zendawg
Thank you for the PR.
This (initially) feels like it could grow into a mini Apache Commons Configuration or an add-on to it but I do see the missing feature compared to JCommander and picocli.
It seems like something we could do in a 2.0. ATM I am gathering small changes for a 1.5.
What do others think?
Hi @zendawg
Thank you for the PR.
This (initially) feels like it could grow into a mini Apache Commons Configuration or an add-on to it but I do see the missing feature compared to JCommander and picocli.
It seems like something we could do in a 2.0. ATM I am gathering small changes for a 1.5.
What do others think?
Hi @garydgregory,
I have to admit I didn't think this would be taken up so we moved ahead and hosted this internally; I've not updated my public sources since when I originally posted the proposed changes.
Since then we've created a wrapper project - so as not to pollute the main commons-cli library - i.e. moved our souces up one level with a dependency on commons-cli. Either way, it wouldn't be difficult to re-incorporate the code. This would give users the option of using commons-cli on it's own, or instead using the configuration wrapper (i.e. the original code I had added). It would be great if Apache wanted to use it, let me know and I'll sort out putting my latest changes in. Personally I would rather merge the current (non-public) code changes we made back into the same project since that seems to make more sense rather than having two libraries.
A lot of changes have been added - such as object types and properties for CLI arguments (Integer, File etc.) and things like minimum/maximum and default values, as well as properties for file types (must be a directory, must exist/not exist etc.), to prevent library users having to write too much code.
Also, current work includes a set of separate projects such as command-line tools to auto-generate configurations (via an interactive command line tool) as well as source code generation based on a configuration file to produce wrapper bean classes for options so that again reduces overhead for programming the library for your own uses. Also a small set of examples directories with mini projects to showcase how the library can be used. The main library README has also been updated with more detailed usage (originally I just posted the sources with unit tests as I thought that would be enough). Clearly this would be a separate project (e.g. commons-cli-tools) rather than put them in the main library.
We originally developed this since we were creating a lot of CLI-based executables some of which had 30 options (or so) and wanted to cut down on code overhead. It worked and has been well accepted, hence the new set of tools to finalise some of the work we're doing.
My only hesitation for inclusion in Apache Commons Configuration would be that it introduce a dependency on commons-cli, which doesn't quite fit right (in my view), although I am open to suggestions.
Perhaps the best thing to do would be finish the tools I'm currently working on then give you folks a nudge so you can take a look?