[jira] [Resolved] (GROOVY-6090) Reimplement CliBuilder over another CLI API

["Paul King (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King resolved GROOVY-6090.
-------------------------------
       Resolution: Fixed
    Fix Version/s: 2.5.0-beta-1

OK, I've cheated and used Commons CLI 1.3 as the "other" CLI API. Moving to something else completely is still something that can be considered but DefaultParser seems to fix the major outstanding bugs we were annoyed with. And also given that Groovy and Commons CLI are now both Apache and the Commons CLI project seems to be at least moving slowly again, I think we need to have a fresh look at such a move. I'll close this issue, since much of the discussion is now outdated, but feel free to open a new one if you feel strongly about this issue. We should base the discussion/comparison with other APIs on what CLI 1.3 now provides us with.

> Reimplement CliBuilder over another CLI API
> -------------------------------------------
>
>                 Key: GROOVY-6090
>                 URL: https://issues.apache.org/jira/browse/GROOVY-6090
>             Project: Groovy
>          Issue Type: Wish
>          Components: command line processing
>    Affects Versions: 2.1.2
>            Reporter: Baruch Sadogursky
>            Assignee: Paul King
>            Priority: Minor
>             Fix For: 2.5.0-beta-1
>
>
> current CliBuilder implementation is based on the dead and outdated commons-cli project, which affects its flexibility, API, design and fimits its features.
> There are better alternatives - commons-cli2, args4j, jcommander, to name a few.
> CLI processing is critical feature for Groovy scripts usability, and lacking in it drive people away (even devoted Groovy advocates like @russel_winder) and prevents adoption.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)