You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Remko Popma <re...@gmail.com> on 2018/03/20 17:26:19 UTC
next generation CliBuilder?
Would there be any interest in a next generation CliBuilder that is
based on [picocli][1] instead of commons-cli?
This would enable new features like:
* support for nested [subcommands][2]
* strongly typed [positional parameters][3]
* command line [autocompletion][4]
* [ANSI colors][5] in usage help message
Picocli is actively maintained and developed. The next major
release (3.0) includes a [programmatic API][6] in addition
to the annotations API.
If there is any interest, I would be happy to do the work
to develop, create tests and document such a next generation
CliBuilder (CliBuilder2?). I was thinking to try to make the
API very similar to the current CliBuilder to facilitate user
migration, but I am open to suggestions.
Thoughts?
[1]: https://github.com/remkop/picocli
[2]: http://picocli.info/index.html#_subcommands
[3]: http://picocli.info/index.html#_positional_parameters
[4]: http://picocli.info/autocomplete.html
[5]: http://picocli.info/index.html#_ansi_colors_and_styles
[6]: https://github.com/remkop/picocli/wiki/Programmatic-API
Re: next generation CliBuilder?
Posted by Remko Popma <re...@gmail.com>.
Makes sense.
I’ll run with that.
On Wed, Mar 21, 2018 at 14:48 Paul King <pa...@asert.com.au> wrote:
> I would suggest (initially) leaving the current annotations and its
> behavior exactly as is. Just replace the commons cli api usage with picocli
> api usage. The same goes for the "dynamic" flavor of using CliBuilder -
> just mimic the current behavior as exactly as possible.
>
> This won't give support for the picocli annotations (unless that came for
> "free") or provide full feature parity but we can add more features over
> time if we want. I would see the first cut as providing an extra level of
> Groovy friendliness over and above "vanilla" picocli for the common cases.
> There is nothing stopping people from using picocli directly if they need
> the other features and we could add more features like an "index"
> attribute to @Unparsed at our leisure in a backward compatible way.
>
> What do you think?
>
> Paul.
>
>
> On Wed, Mar 21, 2018 at 2:38 PM, Remko Popma <re...@gmail.com>
> wrote:
>
>>
>> On Wed, Mar 21, 2018 at 12:43 Paul King <pa...@asert.com.au> wrote:
>>
>>> On Wed, Mar 21, 2018 at 11:11 AM, Paul King <pa...@asert.com.au> wrote:
>>>
>>>> Picocli has always looked like a nice alternative. It wasn't an option
>>>> for me before it had the api but picocli 3 seems to have that covered. The
>>>> jar is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder
>>>> supports strong typing for options at the api level without having to
>>>> specify a default value. I don't think the picocli api supports this but
>>>> neither did commons cli, so perhaps that can be catered for in a reworked
>>>> CliBuilder similar to how we do it now.
>>>>
>>>> My main reservation is we haven't received a lot of feedback on our
>>>> existing annotations API and strong typing support in 2.5. But if we had a
>>>> fully backward compatible drop-in replacement, I wouldn't be against it.
>>>>
>>>
>>> And, I guess if we had a solution in the next month, full compatibility
>>> with the yet to be released 2.5 features would be less of a concern.
>>>
>>
>> Next month should be possible.
>>
>> There is certainly some overlap between the groovy.cli.Option annotation
>> introduced in groovy 2.5 alpha and the picocli Option annotation. Are you
>> thinking the groovy.cli.Option could be replaced by the picocli annotation
>> or should the new CliBuilder support both?
>>
>> Supporting both means remaining compatible with the groovy 2.5 alpha API,
>> but there is no groovy equivalent of the picocli annotations for commands
>> and typed positional parameters, so the set of groovy.cli annotations would
>> not be as coherent or full-featured.
>>
>> Either is possible, it's just where you want to take this in the future.
>> I'm already happy with your positive response.
>>
>>
>>>
>>>> Cheers, Paul.
>>>>
>>>> On Wed, Mar 21, 2018 at 5:09 AM, MG <mg...@arscreat.com> wrote:
>>>>
>>>>> Hi Russell,
>>>>>
>>>>> I have not tried picocli myself, but strongly typed parameters + good
>>>>> looking annotations API + actively maintained + Groovy enthusiast offering
>>>>> to integrate it into Groovy sounds good to me... ||-)
>>>>>
>>>>> Does anyone knows of any shortcomings of picocli or miss some CLI
>>>>> features in the library ? Or are there any other (long running) plans to
>>>>> replace the existing CliBuilder implementation ?
>>>>>
>>>>> Cheers,
>>>>> mg
>>>>>
>>>>>
>>>>>
>>>>> On 20.03.2018 19:13, Russel Winder wrote:
>>>>>
>>>>>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>>>>>
>>>>>>> Would there be any interest in a next generation CliBuilder that is
>>>>>>> based on [picocli][1] instead of commons-cli?
>>>>>>>
>>>>>> Personally I am all for a new CLI system for Groovy. There are though
>>>>>> many different CLI frameworks already out there, many have previously
>>>>>> been discussed in various threads on this list. Indeed I think there
>>>>>> has been some work, but none that got absorbed into the standard
>>>>>> Groovy
>>>>>> distribution.
>>>>>>
>>>>>> So the question for me is not how to replace commons-cli just what to
>>>>>> do. So the question for me is what distinguishes picocli from all the
>>>>>> other options.
>>>>>>
>>>>>> […]
>>>>>>>
>>>>>>
>>>>>
>>>>
>
Re: next generation CliBuilder?
Posted by Paul King <pa...@asert.com.au>.
I would suggest (initially) leaving the current annotations and its
behavior exactly as is. Just replace the commons cli api usage with picocli
api usage. The same goes for the "dynamic" flavor of using CliBuilder -
just mimic the current behavior as exactly as possible.
This won't give support for the picocli annotations (unless that came for
"free") or provide full feature parity but we can add more features over
time if we want. I would see the first cut as providing an extra level of
Groovy friendliness over and above "vanilla" picocli for the common cases.
There is nothing stopping people from using picocli directly if they need
the other features and we could add more features like an "index" attribute
to @Unparsed at our leisure in a backward compatible way.
What do you think?
Paul.
On Wed, Mar 21, 2018 at 2:38 PM, Remko Popma <re...@gmail.com> wrote:
>
> On Wed, Mar 21, 2018 at 12:43 Paul King <pa...@asert.com.au> wrote:
>
>> On Wed, Mar 21, 2018 at 11:11 AM, Paul King <pa...@asert.com.au> wrote:
>>
>>> Picocli has always looked like a nice alternative. It wasn't an option
>>> for me before it had the api but picocli 3 seems to have that covered. The
>>> jar is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder
>>> supports strong typing for options at the api level without having to
>>> specify a default value. I don't think the picocli api supports this but
>>> neither did commons cli, so perhaps that can be catered for in a reworked
>>> CliBuilder similar to how we do it now.
>>>
>>> My main reservation is we haven't received a lot of feedback on our
>>> existing annotations API and strong typing support in 2.5. But if we had a
>>> fully backward compatible drop-in replacement, I wouldn't be against it.
>>>
>>
>> And, I guess if we had a solution in the next month, full compatibility
>> with the yet to be released 2.5 features would be less of a concern.
>>
>
> Next month should be possible.
>
> There is certainly some overlap between the groovy.cli.Option annotation
> introduced in groovy 2.5 alpha and the picocli Option annotation. Are you
> thinking the groovy.cli.Option could be replaced by the picocli annotation
> or should the new CliBuilder support both?
>
> Supporting both means remaining compatible with the groovy 2.5 alpha API,
> but there is no groovy equivalent of the picocli annotations for commands
> and typed positional parameters, so the set of groovy.cli annotations would
> not be as coherent or full-featured.
>
> Either is possible, it's just where you want to take this in the future.
> I'm already happy with your positive response.
>
>
>>
>>> Cheers, Paul.
>>>
>>> On Wed, Mar 21, 2018 at 5:09 AM, MG <mg...@arscreat.com> wrote:
>>>
>>>> Hi Russell,
>>>>
>>>> I have not tried picocli myself, but strongly typed parameters + good
>>>> looking annotations API + actively maintained + Groovy enthusiast offering
>>>> to integrate it into Groovy sounds good to me... ||-)
>>>>
>>>> Does anyone knows of any shortcomings of picocli or miss some CLI
>>>> features in the library ? Or are there any other (long running) plans to
>>>> replace the existing CliBuilder implementation ?
>>>>
>>>> Cheers,
>>>> mg
>>>>
>>>>
>>>>
>>>> On 20.03.2018 19:13, Russel Winder wrote:
>>>>
>>>>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>>>>
>>>>>> Would there be any interest in a next generation CliBuilder that is
>>>>>> based on [picocli][1] instead of commons-cli?
>>>>>>
>>>>> Personally I am all for a new CLI system for Groovy. There are though
>>>>> many different CLI frameworks already out there, many have previously
>>>>> been discussed in various threads on this list. Indeed I think there
>>>>> has been some work, but none that got absorbed into the standard Groovy
>>>>> distribution.
>>>>>
>>>>> So the question for me is not how to replace commons-cli just what to
>>>>> do. So the question for me is what distinguishes picocli from all the
>>>>> other options.
>>>>>
>>>>> […]
>>>>>>
>>>>>
>>>>
>>>
Re: next generation CliBuilder?
Posted by Remko Popma <re...@gmail.com>.
On Wed, Mar 21, 2018 at 12:43 Paul King <pa...@asert.com.au> wrote:
> On Wed, Mar 21, 2018 at 11:11 AM, Paul King <pa...@asert.com.au> wrote:
>
>> Picocli has always looked like a nice alternative. It wasn't an option
>> for me before it had the api but picocli 3 seems to have that covered. The
>> jar is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder
>> supports strong typing for options at the api level without having to
>> specify a default value. I don't think the picocli api supports this but
>> neither did commons cli, so perhaps that can be catered for in a reworked
>> CliBuilder similar to how we do it now.
>>
>> My main reservation is we haven't received a lot of feedback on our
>> existing annotations API and strong typing support in 2.5. But if we had a
>> fully backward compatible drop-in replacement, I wouldn't be against it.
>>
>
> And, I guess if we had a solution in the next month, full compatibility
> with the yet to be released 2.5 features would be less of a concern.
>
Next month should be possible.
There is certainly some overlap between the groovy.cli.Option annotation
introduced in groovy 2.5 alpha and the picocli Option annotation. Are you
thinking the groovy.cli.Option could be replaced by the picocli annotation
or should the new CliBuilder support both?
Supporting both means remaining compatible with the groovy 2.5 alpha API,
but there is no groovy equivalent of the picocli annotations for commands
and typed positional parameters, so the set of groovy.cli annotations would
not be as coherent or full-featured.
Either is possible, it's just where you want to take this in the future.
I'm already happy with your positive response.
>
>> Cheers, Paul.
>>
>> On Wed, Mar 21, 2018 at 5:09 AM, MG <mg...@arscreat.com> wrote:
>>
>>> Hi Russell,
>>>
>>> I have not tried picocli myself, but strongly typed parameters + good
>>> looking annotations API + actively maintained + Groovy enthusiast offering
>>> to integrate it into Groovy sounds good to me... ||-)
>>>
>>> Does anyone knows of any shortcomings of picocli or miss some CLI
>>> features in the library ? Or are there any other (long running) plans to
>>> replace the existing CliBuilder implementation ?
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>
>>> On 20.03.2018 19:13, Russel Winder wrote:
>>>
>>>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>>>
>>>>> Would there be any interest in a next generation CliBuilder that is
>>>>> based on [picocli][1] instead of commons-cli?
>>>>>
>>>> Personally I am all for a new CLI system for Groovy. There are though
>>>> many different CLI frameworks already out there, many have previously
>>>> been discussed in various threads on this list. Indeed I think there
>>>> has been some work, but none that got absorbed into the standard Groovy
>>>> distribution.
>>>>
>>>> So the question for me is not how to replace commons-cli just what to
>>>> do. So the question for me is what distinguishes picocli from all the
>>>> other options.
>>>>
>>>> […]
>>>>>
>>>>
>>>
>>
Re: next generation CliBuilder?
Posted by Paul King <pa...@asert.com.au>.
On Wed, Mar 21, 2018 at 11:11 AM, Paul King <pa...@asert.com.au> wrote:
> Picocli has always looked like a nice alternative. It wasn't an option for
> me before it had the api but picocli 3 seems to have that covered. The jar
> is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder supports
> strong typing for options at the api level without having to specify a
> default value. I don't think the picocli api supports this but neither did
> commons cli, so perhaps that can be catered for in a reworked CliBuilder
> similar to how we do it now.
>
> My main reservation is we haven't received a lot of feedback on our
> existing annotations API and strong typing support in 2.5. But if we had a
> fully backward compatible drop-in replacement, I wouldn't be against it.
>
And, I guess if we had a solution in the next month, full compatibility
with the yet to be released 2.5 features would be less of a concern.
> Cheers, Paul.
>
> On Wed, Mar 21, 2018 at 5:09 AM, MG <mg...@arscreat.com> wrote:
>
>> Hi Russell,
>>
>> I have not tried picocli myself, but strongly typed parameters + good
>> looking annotations API + actively maintained + Groovy enthusiast offering
>> to integrate it into Groovy sounds good to me... ||-)
>>
>> Does anyone knows of any shortcomings of picocli or miss some CLI
>> features in the library ? Or are there any other (long running) plans to
>> replace the existing CliBuilder implementation ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> On 20.03.2018 19:13, Russel Winder wrote:
>>
>>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>>
>>>> Would there be any interest in a next generation CliBuilder that is
>>>> based on [picocli][1] instead of commons-cli?
>>>>
>>> Personally I am all for a new CLI system for Groovy. There are though
>>> many different CLI frameworks already out there, many have previously
>>> been discussed in various threads on this list. Indeed I think there
>>> has been some work, but none that got absorbed into the standard Groovy
>>> distribution.
>>>
>>> So the question for me is not how to replace commons-cli just what to
>>> do. So the question for me is what distinguishes picocli from all the
>>> other options.
>>>
>>> […]
>>>>
>>>
>>
>
Re: next generation CliBuilder?
Posted by Remko Popma <re...@gmail.com>.
On Wed, Mar 21, 2018 at 5:23 PM, Jochen Theodorou <bl...@gmx.org> wrote:
>
>
> Am 21.03.2018 um 02:11 schrieb Paul King:
>
>> Picocli has always looked like a nice alternative. It wasn't an option
>> for me before it had the api but picocli 3 seems to have that covered.
>>
>
> can you refresh my memory about the position of JCommander in this? I see
> some overlap. And if we go with Picoli, we should probably explain the
> people in what case they should use what and how.
>
> Fair question. What distinguishes picocli from JCommander (and many other
CLI libraries):
- JCommander has an annotations API, while picocli has both an
annotations and a programmatic API
<https://github.com/remkop/picocli/wiki/Programmatic-API>.
The programmatic API is needed to support the dynamic features of
CliBuilder.
- picocli has easily customized
<http://picocli.info/index.html#_usage_help> usage help with ANSI colors
<http://picocli.info/#_ansi_colors_and_styles>
- picocli-based apps and scripts can have command line autocompletion
<http://picocli.info/autocomplete.html> in bash and zsh
- picocli offers tight integration for Groovy scripts via the
@PicocliScript annotation and AST transformation (see the Groovy Scripts
on Steroids
<http://picocli.info/picocli-2.0-groovy-scripts-on-steroids.html> post)
- in picocli, both options and positional parameters can be strongly
typed. JCommander has strongly typed options, but positional parameters is
an untyped list of strings.
- picocli supports clustered short options
<http://picocli.info/#_short_options>, so you can say <command>
-xvfInputFile as well as <command> -x -v -f=InputFile. JCommander only
supports the latter AFAIK.
- picocli has a range-based arity model that allows a minimum, maximum
and variable number of parameters, e.g, "1..*", "3..5". With JCommander
one needs to choose between minimum arity or variable arity, and with
variable arity one cannot have strong typing
<http://jcommander.org/#_variable_arities> - Strings only.
- picocli has convenience APIs
<http://picocli.info/index.html#_less_boilerplate> that reduce the
boilerplate code for command line applications to a single line of code
Picocli and JCommander both have:
- quality documentation
- support for subcommands
- support for multi-value options, splitting an argument into multiple
values, and map-like options (e.g., -Dkey=value)
JCommander features not in picocli (but on the todo list):
- internationalization
- support for suppressing password echo to the console
- support for case-insensitive and abbreviated options
For more details, this CLI library comparison
<https://github.com/remkop/picocli/wiki/CLI-Comparison> page may be useful.
Dustin Marx‘s article series on command line interfaces, especially the summary
post
<http://marxsoftware.blogspot.jp/2017/11/java-cmd-line-observations.html>,
may also be of interest (although it covers an old version of picocli -
0.9.7).
Remko
> bye Jochen
>
Re: next generation CliBuilder?
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 21.03.2018 um 02:11 schrieb Paul King:
> Picocli has always looked like a nice alternative. It wasn't an option
> for me before it had the api but picocli 3 seems to have that covered.
can you refresh my memory about the position of JCommander in this? I
see some overlap. And if we go with Picoli, we should probably explain
the people in what case they should use what and how.
bye Jochen
Re: next generation CliBuilder?
Posted by Paul King <pa...@asert.com.au>.
Picocli has always looked like a nice alternative. It wasn't an option for
me before it had the api but picocli 3 seems to have that covered. The jar
is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder supports
strong typing for options at the api level without having to specify a
default value. I don't think the picocli api supports this but neither did
commons cli, so perhaps that can be catered for in a reworked CliBuilder
similar to how we do it now.
My main reservation is we haven't received a lot of feedback on our
existing annotations API and strong typing support in 2.5. But if we had a
fully backward compatible drop-in replacement, I wouldn't be against it.
Cheers, Paul.
On Wed, Mar 21, 2018 at 5:09 AM, MG <mg...@arscreat.com> wrote:
> Hi Russell,
>
> I have not tried picocli myself, but strongly typed parameters + good
> looking annotations API + actively maintained + Groovy enthusiast offering
> to integrate it into Groovy sounds good to me... ||-)
>
> Does anyone knows of any shortcomings of picocli or miss some CLI features
> in the library ? Or are there any other (long running) plans to replace the
> existing CliBuilder implementation ?
>
> Cheers,
> mg
>
>
>
> On 20.03.2018 19:13, Russel Winder wrote:
>
>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>
>>> Would there be any interest in a next generation CliBuilder that is
>>> based on [picocli][1] instead of commons-cli?
>>>
>> Personally I am all for a new CLI system for Groovy. There are though
>> many different CLI frameworks already out there, many have previously
>> been discussed in various threads on this list. Indeed I think there
>> has been some work, but none that got absorbed into the standard Groovy
>> distribution.
>>
>> So the question for me is not how to replace commons-cli just what to
>> do. So the question for me is what distinguishes picocli from all the
>> other options.
>>
>> […]
>>>
>>
>
Re: next generation CliBuilder?
Posted by MG <mg...@arscreat.com>.
Hi Russell,
I have not tried picocli myself, but strongly typed parameters + good
looking annotations API + actively maintained + Groovy enthusiast
offering to integrate it into Groovy sounds good to me... ||-)
Does anyone knows of any shortcomings of picocli or miss some CLI
features in the library ? Or are there any other (long running) plans to
replace the existing CliBuilder implementation ?
Cheers,
mg
On 20.03.2018 19:13, Russel Winder wrote:
> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>> Would there be any interest in a next generation CliBuilder that is
>> based on [picocli][1] instead of commons-cli?
> Personally I am all for a new CLI system for Groovy. There are though
> many different CLI frameworks already out there, many have previously
> been discussed in various threads on this list. Indeed I think there
> has been some work, but none that got absorbed into the standard Groovy
> distribution.
>
> So the question for me is not how to replace commons-cli just what to
> do. So the question for me is what distinguishes picocli from all the
> other options.
>
>> […]
Re: next generation CliBuilder?
Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
> Would there be any interest in a next generation CliBuilder that is
> based on [picocli][1] instead of commons-cli?
Personally I am all for a new CLI system for Groovy. There are though
many different CLI frameworks already out there, many have previously
been discussed in various threads on this list. Indeed I think there
has been some work, but none that got absorbed into the standard Groovy
distribution.
So the question for me is not how to replace commons-cli just what to
do. So the question for me is what distinguishes picocli from all the
other options.
> […]
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: next generation CliBuilder?
Posted by MG <mg...@arscreat.com>.
+1 from my side :-)
On 20.03.2018 18:26, Remko Popma wrote:
> Would there be any interest in a next generation CliBuilder that is
> based on [picocli][1] instead of commons-cli?
>
> This would enable new features like:
> * support for nested [subcommands][2]
> * strongly typed [positional parameters][3]
> * command line [autocompletion][4]
> * [ANSI colors][5] in usage help message
>
> Picocli is actively maintained and developed. The next major
> release (3.0) includes a [programmatic API][6] in addition
> to the annotations API.
>
> If there is any interest, I would be happy to do the work
> to develop, create tests and document such a next generation
> CliBuilder (CliBuilder2?). I was thinking to try to make the
> API very similar to the current CliBuilder to facilitate user
> migration, but I am open to suggestions.
>
> Thoughts?
>
> [1]: https://github.com/remkop/picocli
> [2]: http://picocli.info/index.html#_subcommands
> [3]: http://picocli.info/index.html#_positional_parameters
> [4]: http://picocli.info/autocomplete.html
> [5]: http://picocli.info/index.html#_ansi_colors_and_styles
> [6]: https://github.com/remkop/picocli/wiki/Programmatic-API
>