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 12:59:58 GMT
Makes sense, will do. 



> On Mar 25, 2018, at 21:55, Paul King <paulk@asert.com.au> wrote:
> 
> All of those classes are in modules referenced by the groovy-all pom. Swapping those
over will be a separate activity but will be relatively straight forward. It should be transparent
to users of the language bar some slightly different formatting in command-line help messages.
We could do that in a 2.5.1 if needed.
> 
> Let's just progress the CliBuilder replacement first and make sure we are happy with
that.
> 
> Feel free to create some additional Jiras if you want.
> 
> Paul.
> 
> 
>> On Sun, Mar 25, 2018 at 8:55 PM, Remko Popma <remko.popma@gmail.com> wrote:
>> 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