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 12:55:54 GMT
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