Makes sense, will do.
> On Mar 25, 2018, at 21:55, Paul King <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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() >>>> >>> >> >
