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