groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: picocli-based CliBuilder backwards compatibility
Date Sun, 25 Mar 2018 10:55:06 GMT
Thanks, it makes things easier if these properties can be changed.

FYI, the following classes also use commons-cli directly, not sure which
are in the groovy-all jar:


   - org.codehaus.groovy.tools.shell.util.HelpFormatter
   - org.codehaus.groovy.tools.FileSystemCompiler
   - org.codehaus.groovy.tools.GrapeMain
   - groovy.ui.GroovyMain
   - org.codehaus.groovy.ant.Groovyc
   - org.codehaus.groovy.antlr.java.Java2GroovyMain


If the goal is the remove the commons-cli dependency from groovy-all,
should the above classes also be migrated to picocli?

I'll create a JIRA for migrating CliBuilder from commons-cli to picocli).
If you want I can also create a separate JIRA to create a separate
module (groovy-cli-commons or similar) with the existing CliBuilder
implementation (in a separate package). Let me know what you want to do
with the classes above.

Remko



On Sun, Mar 25, 2018 at 4:16 PM, Paul King <paulk@asert.com.au> wrote:

> 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