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