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() >> >> >> >
