groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: picocli-based CliBuilder backwards compatibility
Date Sun, 25 Mar 2018 07:16:10 GMT
I think they are much less widely used than other features so feel free to
change them. If similar functionality is available via picocli, please use
the same property name if it makes sense to expose that functionality for
greater control.

We will likely create a separate module (groovy-cli-commons or similar)
with the existing CliBuilder implementation (but with probably a package
name change) that won't be referenced in the groovy-all pom. If folks are
relying on those bits of the functionality, they can use the legacy
version. The goal should be to have commons-cli being a dependency of only
that module.

Cheers, Paul.

On Sun, Mar 25, 2018 at 1:58 PM, Remko Popma <remko.popma@gmail.com> wrote:

> CliBuilder exposed some commons-cli classes (see below).
>
> Is it okay to remove these, or should these be left as deprecated
> properties in the CliBuilder class to retain binary compatibility with
> pre-2.5 versions?
>
> Note that if these properties remain the new picocli-based implementation
> will ignore them, so the behaviour will change.
>
> /**
>  * Normally set internally but allows you full customisation of the underlying processing
engine.
>  */
> CommandLineParser parser = null
>
> /**
>  * Normally set internally but can be overridden if you want to customise how the usage
message is displayed.
>  */
> HelpFormatter formatter = new HelpFormatter()
>
> /**
>  * Not normally accessed directly but full access to underlying options if needed.
>  */
> Options options = new Options()
>
>
>

Mime
View raw message