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. >>> >>> […] >>>> >>> >> >
