Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New sources for defining CLI options via a configuration file. #32

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

zendawg
Copy link

@zendawg zendawg commented Oct 16, 2019

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.

zendawg added 3 commits October 16, 2019 15:43
- DM_EXIT: Removed System.exit(0) from help 'helper' - callers now required to handle this themselves (tests and documentation updated, all tests pass);
- DM_DEFAULT_ENCODING: changed call to add encoding instead of ignoring it, Javadoc updated;
- SBSC_USE_STRINGBUFFER_CONCATENATION: changed String to StringBuilder, tests updated (all pass)
@coveralls
Copy link

coveralls commented Oct 16, 2019

Coverage Status

Coverage increased (+0.9%) to 97.299% when pulling a56dfdd on zendawg:cli-configuration into 6490067 on apache:master.

zendawg added 4 commits October 16, 2019 18:58
…dded new test configuration files:

- options are now required to be declared in blocks - defining another option after a different option throws an exception;
- redefining an option in the same block throws an exception (e.g. defining option description twice).;
…tion; javadoc updated to clarify parsing rules, new test files added and tests updated accordingly.
@garydgregory
Copy link
Member

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?

@zendawg
Copy link
Author

zendawg commented Oct 19, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants