groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: next generation CliBuilder?
Date Wed, 21 Mar 2018 03:43:37 GMT
On Wed, Mar 21, 2018 at 11:11 AM, Paul King <paulk@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 <mgbiz@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.
>>>
>>> […]
>>>>
>>>
>>
>

Mime
View raw message