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