groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: next generation CliBuilder?
Date Wed, 21 Mar 2018 05:56:46 GMT
Makes sense.
I’ll run with that.

On Wed, Mar 21, 2018 at 14:48 Paul King <paulk@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 <remko.popma@gmail.com>
> wrote:
>
>>
>> On Wed, Mar 21, 2018 at 12:43 Paul King <paulk@asert.com.au> wrote:
>>
>>> 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.
>>>
>>
>> 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 <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