[jira] [Commented] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays
[
https://issues.apache.org/jira/browse/GROOVY-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245592#comment-17245592
]
Remko Popma commented on GROOVY-9817:
-
I verified this works as expected during the 3.0.7 release vote.
Thank you [~paulk] for the fast response! Really great!
> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
> Issue Type: New Feature
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The background for this request is annotations in the
> [picocli|https://picocli.info/] library. The annotations API of this library
> allows applications to specify a class or an array of classes to customize
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class,
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
> the picocli library to allow applications to specify closures for such
> classes in the annotations. For example, I would like applications to be able
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str ->
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value
> attributes like {{completionCandidates}}, but does not work for attributes
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for
> annotations.
> See also
> [discussion|https://lists.apache.org/thread.html/rcd541adf064adb6839b79c889a5778a80739837a58adce523f86e660%40]
> on the groovy-dev mailing list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays
[
https://issues.apache.org/jira/browse/GROOVY-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9817:
Description:
The background for this request is annotations in the
[picocli|https://picocli.info/] library. The annotations API of this library
allows applications to specify a class or an array of classes to customize some
behaviour. For example:
{code:java}
// current picocli (4.5.2) requires explicit class(es), does not support
Closures
@Option(names = "-x",
completionCandidates = MyCandidates.class,
converter = [StringConverter.class, MessageDigestConverter.class])
Map someOption;
{code}
There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
the picocli library to allow applications to specify closures for such classes
in the annotations. For example, I would like applications to be able to do
this:
{code:java}
// next version of picocli (4.6.0) aims to support Closures in these annotation
attributes
@picocli.CommandLine.Option(names = "-x",
completionCandidates = {["A", "B", "C"]},
converter = [ {it}, { str ->
java.security.MessageDigest.getInstance(str) } ])
Map someOption
{code}
With the current version of Groovy (3.0.6), this works for the single-value
attributes like {{completionCandidates}}, but does not work for attributes that
take an array of values, like {{converter}}.
Please add support for arrays in the Closure to Class conversion for
annotations.
See also
[discussion|https://lists.apache.org/thread.html/rcd541adf064adb6839b79c889a5778a80739837a58adce523f86e660%40]
on the groovy-dev mailing list.
was:
The background for this request is annotations in the
[picocli|https://picocli.info/] library. The annotations API of this library
allows applications to specify a class or an array of classes to customize some
behaviour. For example:
{code:java}
// current picocli (4.5.2) requires explicit class(es), does not support
Closures
@Option(names = "-x",
completionCandidates = MyCandidates.class,
converter = [StringConverter.class, MessageDigestConverter.class])
Map someOption;
{code}
There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
the picocli library to allow applications to specify closures for such classes
in the annotations. For example, I would like applications to be able to do
this:
{code:java}
// next version of picocli (4.6.0) aims to support Closures in these annotation
attributes
@picocli.CommandLine.Option(names = "-x",
completionCandidates = {["A", "B", "C"]},
converter = [ {it}, { str ->
java.security.MessageDigest.getInstance(str) } ])
Map someOption
{code}
With the current version of Groovy (3.0.6), this works for the single-value
attributes like {{completionCandidates}}, but does not work for attributes that
take an array of values, like {{converter}}.
Please add support for arrays in the Closure to Class conversion for
annotations.
> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
> Issue Type: New Feature
>Reporter: Paul King
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The background for this request is annotations in the
> [picocli|https://picocli.info/] library. The annotations API of this library
> allows applications to specify a class or an array of classes to customize
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class,
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
> the picocli library to allow applications to specify closures for such
> classes in the annotations. For example, I would like applications to be able
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str ->
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value
> attributes like {{completionCandidates}}, but does not work for attributes
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for
> annotations.
> See also
>
[jira] [Updated] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays
[
https://issues.apache.org/jira/browse/GROOVY-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9817:
Issue Type: New Feature (was: Dependency upgrade)
> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
> Issue Type: New Feature
>Reporter: Paul King
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The background for this request is annotations in the
> [picocli|https://picocli.info/] library. The annotations API of this library
> allows applications to specify a class or an array of classes to customize
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class,
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
> the picocli library to allow applications to specify closures for such
> classes in the annotations. For example, I would like applications to be able
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str ->
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value
> attributes like {{completionCandidates}}, but does not work for attributes
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for
> annotations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays
[
https://issues.apache.org/jira/browse/GROOVY-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9817:
Description:
The background for this request is annotations in the
[picocli|https://picocli.info/] library. The annotations API of this library
allows applications to specify a class or an array of classes to customize some
behaviour. For example:
{code:java}
// current picocli (4.5.2) requires explicit class(es), does not support
Closures
@Option(names = "-x",
completionCandidates = MyCandidates.class,
converter = [StringConverter.class, MessageDigestConverter.class])
Map someOption;
{code}
There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
the picocli library to allow applications to specify closures for such classes
in the annotations. For example, I would like applications to be able to do
this:
{code:java}
// next version of picocli (4.6.0) aims to support Closures in these annotation
attributes
@picocli.CommandLine.Option(names = "-x",
completionCandidates = {["A", "B", "C"]},
converter = [ {it}, { str ->
java.security.MessageDigest.getInstance(str) } ])
Map someOption
{code}
With the current version of Groovy (3.0.6), this works for the single-value
attributes like {{completionCandidates}}, but does not work for attributes that
take an array of values, like {{converter}}.
Please add support for arrays in the Closure to Class conversion for
annotations.
> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
> Issue Type: Dependency upgrade
>Reporter: Paul King
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The background for this request is annotations in the
> [picocli|https://picocli.info/] library. The annotations API of this library
> allows applications to specify a class or an array of classes to customize
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class,
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in
> the picocli library to allow applications to specify closures for such
> classes in the annotations. For example, I would like applications to be able
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str ->
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value
> attributes like {{completionCandidates}}, but does not work for attributes
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for
> annotations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141628#comment-17141628
]
Remko Popma commented on GROOVY-9519:
-
[~dheinric], you are right, I did miss it when you raised it here originally.
Thanks for following up!
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue ''" (empty String) results in NullObject if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-9599.
-
Resolution: Fixed
> CliBuilder: Option with "type: String, defaultValue ''" (empty String)
> results in NullObject if default value is applied
>
>
> Key: GROOVY-9599
> URL: https://issues.apache.org/jira/browse/GROOVY-9599
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 2.5.11, 3.0.4
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.5, 2.5.13
>
>
> This is a follow-up ticket for GROOVY-9519:
> After checking with Groovy 3.0.4, it seems that only the "Integer with
> defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
> latter became even worse. It still ignores the defaultValue, but instead of
> creating a Boolean, it now creates a NullObject. Try this code:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.3.2')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
> '', 'Option a (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.a.getClass())
> if (opts.a) {
> println(opts.a)
> }
> {code}
> with Groovy 3.0.2:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> {code}
> and with Groovy 3.0.4:
> {code:java}
> % ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
> class org.codehaus.groovy.runtime.NullObject
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue ''" (empty String) results in NullObject if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141625#comment-17141625
]
Remko Popma commented on GROOVY-9599:
-
Fix and additional test committed to the
[master|https://github.com/apache/groovy/commit/16a5c42e53c440d3675d7b7cb91113a584663b86],
[GROOVY_3_0_X|https://github.com/apache/groovy/commit/829b19c7bcc91b3aa80f16379f980dc5dcdf9c64]
and
[GROOVY_2_5_X|https://github.com/apache/groovy/commit/ede7ffca2bf151471cfc888ee41d4c4f68d3d906]
branches.
Test results look good in [CI|https://groovy.apache.org/buildstatus.html]
([master|https://ci.groovy-lang.org/viewLog.html?buildId=2154=MasterTestJdk8],
[3.0|https://ci.groovy-lang.org/viewLog.html?buildId=2151=Groovy30xTestAllJdk8],
[2.5|https://ci.groovy-lang.org/viewLog.html?buildId=2159=Groovy25xCheckJdk8])
Resolving this ticket as fixed.
> CliBuilder: Option with "type: String, defaultValue ''" (empty String)
> results in NullObject if default value is applied
>
>
> Key: GROOVY-9599
> URL: https://issues.apache.org/jira/browse/GROOVY-9599
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 2.5.11, 3.0.4
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.5, 2.5.13
>
>
> This is a follow-up ticket for GROOVY-9519:
> After checking with Groovy 3.0.4, it seems that only the "Integer with
> defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
> latter became even worse. It still ignores the defaultValue, but instead of
> creating a Boolean, it now creates a NullObject. Try this code:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.3.2')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
> '', 'Option a (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.a.getClass())
> if (opts.a) {
> println(opts.a)
> }
> {code}
> with Groovy 3.0.2:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> {code}
> and with Groovy 3.0.4:
> {code:java}
> % ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
> class org.codehaus.groovy.runtime.NullObject
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue ''" (empty String) results in NullObject if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9599:
Affects Version/s: 2.5.11
> CliBuilder: Option with "type: String, defaultValue ''" (empty String)
> results in NullObject if default value is applied
>
>
> Key: GROOVY-9599
> URL: https://issues.apache.org/jira/browse/GROOVY-9599
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 2.5.11, 3.0.4
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.5
>
>
> This is a follow-up ticket for GROOVY-9519:
> After checking with Groovy 3.0.4, it seems that only the "Integer with
> defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
> latter became even worse. It still ignores the defaultValue, but instead of
> creating a Boolean, it now creates a NullObject. Try this code:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.3.2')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
> '', 'Option a (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.a.getClass())
> if (opts.a) {
> println(opts.a)
> }
> {code}
> with Groovy 3.0.2:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> {code}
> and with Groovy 3.0.4:
> {code:java}
> % ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
> class org.codehaus.groovy.runtime.NullObject
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue ''" (empty String) results in NullObject if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9599:
Fix Version/s: 2.5.13
> CliBuilder: Option with "type: String, defaultValue ''" (empty String)
> results in NullObject if default value is applied
>
>
> Key: GROOVY-9599
> URL: https://issues.apache.org/jira/browse/GROOVY-9599
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 2.5.11, 3.0.4
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.5, 2.5.13
>
>
> This is a follow-up ticket for GROOVY-9519:
> After checking with Groovy 3.0.4, it seems that only the "Integer with
> defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
> latter became even worse. It still ignores the defaultValue, but instead of
> creating a Boolean, it now creates a NullObject. Try this code:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.3.2')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
> '', 'Option a (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.a.getClass())
> if (opts.a) {
> println(opts.a)
> }
> {code}
> with Groovy 3.0.2:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> {code}
> and with Groovy 3.0.4:
> {code:java}
> % ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
> class org.codehaus.groovy.runtime.NullObject
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue ''" (empty String) results in NullObject if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141605#comment-17141605
]
Remko Popma commented on GROOVY-9599:
-
This turned out to have a separate, very different cause from GROOVY-9519.
Given code like this:
{code:java}
def cli = new CliBuilder()
cli.s(type: String, longOpt: 'str', required: false, args: 1, defaultValue: '',
'description')
{code}
the {{groovy.cli.picocli.CliBuilder}} class constructs a
{{picocli.CommandLine.Model.OptionSpec}} from the method arguments.
These method arguments are given to the conversion logic as a {{Map}}. During this conversion, there is the following conditional that
prevents all options from getting an empty String value as their default value:
{code:java}
// Map m
if (!m.defaultValue) { //<-- (line 943) BAD: evaluates to false if value is
empty String.
m.remove('defaultValue') // don't default the picocli model to empty string
}
{code}
This works fine when no default is specified, or when the default is specified
as something that does not evaluate to {{false}} as per Groovy Truthiness, but
when an empty String is intentionally specified as the default, what actually
happens is that the default value becomes {{null}}.
The correct code should just look at the absence or presence of the
"defaultValue" key in the map:
{code:java}
if (!m.containsKey('defaultValue')) { // GROOVY-9599
m.remove('defaultValue') // don't default the picocli model to empty string
}
{code}
I will commit a fix and an additional test soon.
> CliBuilder: Option with "type: String, defaultValue ''" (empty String)
> results in NullObject if default value is applied
>
>
> Key: GROOVY-9599
> URL: https://issues.apache.org/jira/browse/GROOVY-9599
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.4
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.5
>
>
> This is a follow-up ticket for GROOVY-9519:
> After checking with Groovy 3.0.4, it seems that only the "Integer with
> defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
> latter became even worse. It still ignores the defaultValue, but instead of
> creating a Boolean, it now creates a NullObject. Try this code:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.3.2')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
> '', 'Option a (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.a.getClass())
> if (opts.a) {
> println(opts.a)
> }
> {code}
> with Groovy 3.0.2:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> {code}
> and with Groovy 3.0.4:
> {code:java}
> % ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
> class org.codehaus.groovy.runtime.NullObject
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue ''" (empty String) results in NullObject if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9599:
Summary: CliBuilder: Option with "type: String, defaultValue ''" (empty
String) results in NullObject if default value is applied (was: CliBuilder:
Option with "type: String, defaultValue 'x'" results in NullObject if default
value is applied)
> CliBuilder: Option with "type: String, defaultValue ''" (empty String)
> results in NullObject if default value is applied
>
>
> Key: GROOVY-9599
> URL: https://issues.apache.org/jira/browse/GROOVY-9599
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.4
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.5
>
>
> This is a follow-up ticket for GROOVY-9519:
> After checking with Groovy 3.0.4, it seems that only the "Integer with
> defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
> latter became even worse. It still ignores the defaultValue, but instead of
> creating a Boolean, it now creates a NullObject. Try this code:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.3.2')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
> '', 'Option a (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.a.getClass())
> if (opts.a) {
> println(opts.a)
> }
> {code}
> with Groovy 3.0.2:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> {code}
> and with Groovy 3.0.4:
> {code:java}
> % ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
> class org.codehaus.groovy.runtime.NullObject
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed GROOVY-9519.
---
Resolution: Fixed
Hi [~dheinric], thank you for raising this!
I created a separate ticket: https://issues.apache.org/jira/browse/GROOVY-9599
to track the issue with String defaults, and linked it to this ticket. I will
close this ticket, because the boolean default problem was fixed in 3.0.4.
That makes it easier to track which issue was fixed in which release.
Please add yourself as a watcher to GROOVY-9599 to be notified of updates.
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.5.12, 3.0.4
>
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9599) CliBuilder: Option with "type: String, defaultValue 'x'" results in NullObject if default value is applied
Remko Popma created GROOVY-9599:
---
Summary: CliBuilder: Option with "type: String, defaultValue 'x'"
results in NullObject if default value is applied
Key: GROOVY-9599
URL: https://issues.apache.org/jira/browse/GROOVY-9599
Project: Groovy
Issue Type: Bug
Components: command line processing
Affects Versions: 3.0.4
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 3.0.5
This is a follow-up ticket for GROOVY-9519:
After checking with Groovy 3.0.4, it seems that only the "Integer with
defaultValue '0'" case was fixed, but not "String with defaultValue ''". The
latter became even worse. It still ignores the defaultValue, but instead of
creating a Boolean, it now creates a NullObject. Try this code:
{code:java}
@Grab('info.picocli:picocli-groovy:4.3.2')
@GrabConfig(systemClassLoader=true)
import groovy.cli.picocli.CliBuilder
def cli = new CliBuilder(name: 'cliTest.groovy', stopAtNonOption: false)
cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
usage information')
cli.a(type: String, longOpt: 'optA', required: false, args: 1, defaultValue:
'', 'Option a (optional)')
def opts = cli.parse(args)
opts || System.exit(1)
if(opts.h) {
cli.usage()
System.exit(0)
}
println(opts.a.getClass())
if (opts.a) {
println(opts.a)
}
{code}
with Groovy 3.0.2:
{code:java}
% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
class java.lang.Boolean
{code}
and with Groovy 3.0.4:
{code:java}
% ~/tmp/groovy-3.0.4/bin/groovy ./cliTest.groovy
class org.codehaus.groovy.runtime.NullObject
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9553) Bump picocli to 4.3.2
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved GROOVY-9553. - Resolution: Fixed > Bump picocli to 4.3.2 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to [4.3.2|https://github.com/remkop/picocli/releases/tag/v4.3.2]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9553) Bump picocli to 4.3.2
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109260#comment-17109260 ] Remko Popma commented on GROOVY-9553: - This is done now in the master, 3_0_X and 2_5_X branches. > Bump picocli to 4.3.2 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to [4.3.2|https://github.com/remkop/picocli/releases/tag/v4.3.2]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9553) Bump picocli to 4.3.2
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9553: Description: Bump picocli to [4.3.2|https://github.com/remkop/picocli/releases/tag/v4.3.2]. (was: Bump picocli to [4.3.1|https://github.com/remkop/picocli/releases/tag/v4.3.1].) > Bump picocli to 4.3.2 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to [4.3.2|https://github.com/remkop/picocli/releases/tag/v4.3.2]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9553) Bump picocli to 4.3.2
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109039#comment-17109039 ] Remko Popma commented on GROOVY-9553: - Yes, 4.3.2 should be okay. I can do it tomorrow morning, family time for me now... > Bump picocli to 4.3.2 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to [4.3.1|https://github.com/remkop/picocli/releases/tag/v4.3.1]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-8934) Groovy 2.5 introduced a bootstrap loop
[
https://issues.apache.org/jira/browse/GROOVY-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109037#comment-17109037
]
Remko Popma edited comment on GROOVY-8934 at 5/16/20, 12:34 PM:
I believe [~paulk] is correct and this should no longer be an issue.
Prior to picocli 4.0, the picocli jar did indeed contain some classes that
depend on Groovy. In the picocli 4.0 release, these classes were split off from
the picocli artifact into a separate artifact {{picocli-groovy}}.
Groovy itself does not use the {{picocli-groovy}} artifact, only {{picocli}}.
[~roptat] can you try again with a recent version of Groovy?
was (Author: rem...@yahoo.com):
I believe [~paulk] is correct and this should no longer be an issue.
Prior to picocli 4.0, the picocli jar did indeed contain some classes that
depend on Groovy. In the 4.0 release, these classes were split off from the
picocli artifact into a separate artifact {{picocli-groovy}}.
Groovy itself does not use the {{picocli-groovy}} artifact, only {{picocli}}.
[~roptat] can you try again with a recent version of Groovy?
> Groovy 2.5 introduced a bootstrap loop
> --
>
> Key: GROOVY-8934
> URL: https://issues.apache.org/jira/browse/GROOVY-8934
> Project: Groovy
> Issue Type: Bug
>Reporter: julien lepiller
>Priority: Major
>
> Hi,
> I'm a packager in Guix and I'm interested in getting the java stack packaged
> in Guix. We already have a package for Groovy 2.4.15
> ([https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/groovy.scm])
> that I'm trying to update to the latest version. This old version was
> perfectly bootstrappable, meaning that I was able to build Groovy without a
> pre-existing Groovy compiler. I only had to ignore Gradle (because it depends
> on Groovy) and somewhat emulate its behavior with simpler tools. This works
> well and I'm able to build most of Gradle with it!
> During the update process, I realised that Groovy now requires picocli. When
> I tried to package it, I discovered that it depends on Groovy. This
> introduces a bootstrap loop that I need to break, as I can no longer build
> Groovy without itself. Would you consider removing picocli to make Groovy
> bootstrappable (in the sense of
> [https://bootstrappable.org|https://bootstrappable.org)/]) again in future
> releases?
> Another solution for us is to update to the latest version in the 2.4 series,
> build picocli with it, and then use that to build the latest Groovy. This is
> less nice, because future versions of picocli might require intermediate
> versions of Groovy, which will eventually create a long chain of compilers,
> but could work as well.
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-8934) Groovy 2.5 introduced a bootstrap loop
[
https://issues.apache.org/jira/browse/GROOVY-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109037#comment-17109037
]
Remko Popma commented on GROOVY-8934:
-
I believe [~paulk] is correct and this should no longer be an issue.
Prior to picocli 4.0, the picocli jar did indeed contain some classes that
depend on Groovy. In the 4.0 release, these classes were split off from the
picocli artifact into a separate artifact {{picocli-groovy}}.
Groovy itself does not use the {{picocli-groovy}} artifact, only {{picocli}}.
[~roptat] can you try again with a recent version of Groovy?
> Groovy 2.5 introduced a bootstrap loop
> --
>
> Key: GROOVY-8934
> URL: https://issues.apache.org/jira/browse/GROOVY-8934
> Project: Groovy
> Issue Type: Bug
>Reporter: julien lepiller
>Priority: Major
>
> Hi,
> I'm a packager in Guix and I'm interested in getting the java stack packaged
> in Guix. We already have a package for Groovy 2.4.15
> ([https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/groovy.scm])
> that I'm trying to update to the latest version. This old version was
> perfectly bootstrappable, meaning that I was able to build Groovy without a
> pre-existing Groovy compiler. I only had to ignore Gradle (because it depends
> on Groovy) and somewhat emulate its behavior with simpler tools. This works
> well and I'm able to build most of Gradle with it!
> During the update process, I realised that Groovy now requires picocli. When
> I tried to package it, I discovered that it depends on Groovy. This
> introduces a bootstrap loop that I need to break, as I can no longer build
> Groovy without itself. Would you consider removing picocli to make Groovy
> bootstrappable (in the sense of
> [https://bootstrappable.org|https://bootstrappable.org)/]) again in future
> releases?
> Another solution for us is to update to the latest version in the 2.4 series,
> build picocli with it, and then use that to build the latest Groovy. This is
> less nice, because future versions of picocli might require intermediate
> versions of Groovy, which will eventually create a long chain of compilers,
> but could work as well.
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9553) Bump picocli to 4.3.1
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9553: Description: Bump picocli to [4.3.1|[https://github.com/remkop/picocli/releases/tag/v4.3.1]]. (was: Bump picocli to 4.3.1.) > Bump picocli to 4.3.1 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to > [4.3.1|[https://github.com/remkop/picocli/releases/tag/v4.3.1]]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9553) Bump picocli to 4.3.1
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9553: Description: Bump picocli to [4.3.1|https://github.com/remkop/picocli/releases/tag/v4.3.1]. (was: Bump picocli to [4.3.1|[https://github.com/remkop/picocli/releases/tag/v4.3.1]].) > Bump picocli to 4.3.1 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to [4.3.1|https://github.com/remkop/picocli/releases/tag/v4.3.1]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9553) Bump picocli to 4.3.1
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9553: Description: Bump picocli to 4.3.1. (was: Bump picocli to 4.3.0) Summary: Bump picocli to 4.3.1 (was: Bump picocli to 4.3.0) > Bump picocli to 4.3.1 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to 4.3.1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9553) Bump picocli to 4.3.0
[
https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106978#comment-17106978
]
Remko Popma edited comment on GROOVY-9553 at 5/14/20, 7:21 AM:
---
I found an [issue in picocli
4.3.0|https://github.com/remkop/picocli/issues/1043] that impacts CliBuilder.
This will need to be fixed first, so we should skip 4.3.0 and bump to version
4.3.1 instead.
Additionally, the format of an error message has changed, so the following test
needs to be updated with the version bump:
{code:java}
CliBuilderTest.testFailedParsePrintsUsage
Assertion failed:
assert stringWriter.toString() == String.format( "error: Missing required
option '-x'%n" +\ "Usage: groovy -x%n" +\ " -x message%n")
|| | |
| |
|| false |
| 'error: Missing required option \'-x\'%nUsage:
groovy -x%n -x message%n'
|||
'error: Missing required option \'-x\'%nUsage: groovy -x%n'
||'error: Missing required option
\'-x\'\nUsage: groovy -x\n -x message\n'
|'error: Missing required option: \'-x\'\nUsage: groovy -x\n
-x message\n'
error: Missing required option: '-x'
Usage: groovy -x
-x message
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:434)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at
groovy.cli.picocli.CliBuilderTest.testFailedParsePrintsUsage(CliBuilderTest.groovy:164)
{code}
was (Author: rem...@yahoo.com):
I found an [issue in picocli
4.3.0|[https://github.com/remkop/picocli/issues/1043]] that impacts CliBuilder.
This will need to be fixed first, so we should skip 4.3.0 and bump to version
4.3.1 instead.
Additionally, the format of an error message has changed, so the following test
needs to be updated with the version bump:
{code:java}
CliBuilderTest.testFailedParsePrintsUsage
Assertion failed:
assert stringWriter.toString() == String.format( "error: Missing required
option '-x'%n" +\ "Usage: groovy -x%n" +\ " -x message%n")
|| | |
| |
|| false |
| 'error: Missing required option \'-x\'%nUsage:
groovy -x%n -x message%n'
|||
'error: Missing required option \'-x\'%nUsage: groovy -x%n'
||'error: Missing required option
\'-x\'\nUsage: groovy -x\n -x message\n'
|'error: Missing required option: \'-x\'\nUsage: groovy -x\n
-x message\n'
error: Missing required option: '-x'
Usage: groovy -x
-x message
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:434)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at
groovy.cli.picocli.CliBuilderTest.testFailedParsePrintsUsage(CliBuilderTest.groovy:164)
{code}
> Bump picocli to 4.3.0
> -
>
> Key: GROOVY-9553
> URL: https://issues.apache.org/jira/browse/GROOVY-9553
> Project: Groovy
> Issue Type: Dependency upgrade
> Components: command line processing
>Affects Versions: 3.0.3, 2.5.11
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> Bump picocli to 4.3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9553) Bump picocli to 4.3.0
[
https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106978#comment-17106978
]
Remko Popma commented on GROOVY-9553:
-
I found an [issue in picocli
4.3.0|[https://github.com/remkop/picocli/issues/1043]] that impacts CliBuilder.
This will need to be fixed first, so we should skip 4.3.0 and bump to version
4.3.1 instead.
Additionally, the format of an error message has changed, so the following test
needs to be updated with the version bump:
{code:java}
CliBuilderTest.testFailedParsePrintsUsage
Assertion failed:
assert stringWriter.toString() == String.format( "error: Missing required
option '-x'%n" +\ "Usage: groovy -x%n" +\ " -x message%n")
|| | |
| |
|| false |
| 'error: Missing required option \'-x\'%nUsage:
groovy -x%n -x message%n'
|||
'error: Missing required option \'-x\'%nUsage: groovy -x%n'
||'error: Missing required option
\'-x\'\nUsage: groovy -x\n -x message\n'
|'error: Missing required option: \'-x\'\nUsage: groovy -x\n
-x message\n'
error: Missing required option: '-x'
Usage: groovy -x
-x message
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:434)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at
groovy.cli.picocli.CliBuilderTest.testFailedParsePrintsUsage(CliBuilderTest.groovy:164)
{code}
> Bump picocli to 4.3.0
> -
>
> Key: GROOVY-9553
> URL: https://issues.apache.org/jira/browse/GROOVY-9553
> Project: Groovy
> Issue Type: Dependency upgrade
> Components: command line processing
>Affects Versions: 3.0.3, 2.5.11
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> Bump picocli to 4.3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9553) Bump picocli to 4.3.0
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9553: Fix Version/s: 2.5.12 > Bump picocli to 4.3.0 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4, 2.5.12 > > > Bump picocli to 4.3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9553) Bump picocli to 4.3.0
[ https://issues.apache.org/jira/browse/GROOVY-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9553: Affects Version/s: 2.5.11 > Bump picocli to 4.3.0 > - > > Key: GROOVY-9553 > URL: https://issues.apache.org/jira/browse/GROOVY-9553 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 3.0.3, 2.5.11 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.4 > > > Bump picocli to 4.3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9553) Bump picocli to 4.3.0
Remko Popma created GROOVY-9553: --- Summary: Bump picocli to 4.3.0 Key: GROOVY-9553 URL: https://issues.apache.org/jira/browse/GROOVY-9553 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 3.0.3 Reporter: Remko Popma Assignee: Remko Popma Fix For: 3.0.4 Bump picocli to 4.3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9432) ClassNotFoundException when attempting to use Picocli via Grapes
[
https://issues.apache.org/jira/browse/GROOVY-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097038#comment-17097038
]
Remko Popma commented on GROOVY-9432:
-
Reworded as per Paul's suggestion.
I am not sure why {{@GrabConfig(systemClassLoader=true)}} is needed :-) so I
will leave that question to Paul.
> ClassNotFoundException when attempting to use Picocli via Grapes
>
>
> Key: GROOVY-9432
> URL: https://issues.apache.org/jira/browse/GROOVY-9432
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 3.0.0, 3.0.1
> Environment: Reproduced under both macOS (Groovy 3.0.1 installed
> manually and via MacPorts) and Debian (Groovy installed via SDKMAN).
>Reporter: Marc Simpson
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
> Attachments: image-2020-03-03-14-30-10-210.png
>
>
> (Issue originally raised as: https://github.com/remkop/picocli/issues/970)
> Consider the following minimal script:
> {noformat}
> @Grab('info.picocli:picocli:4.2.0')
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder()
> {noformat}
> Under Groovy 2.5.9, this runs without error; with 3.0.1, however, I see:
> {noformat}
> $ groovy cli.groovy
> Caught: java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> at cli.run(cli.groovy:4)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.ClassNotFoundException:
> picocli.CommandLine$ParameterException
> ... 4 more
> {noformat}
> The jar is definitely downloaded to {{~/.groovy/grapes}} and both versions of
> Groovy output
> {noformat}
> Resolving dependency: info.picocli#picocli;4.2.0 {default=[default]}
> Preparing to download artifact info.picocli#picocli;4.2.0!picocli.jar
> {noformat}
> when {{-Dgroovy.grape.report.downloads=true}} is supplied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9432) ClassNotFoundException when attempting to use Picocli via Grapes
[
https://issues.apache.org/jira/browse/GROOVY-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-9432.
-
Resolution: Fixed
> ClassNotFoundException when attempting to use Picocli via Grapes
>
>
> Key: GROOVY-9432
> URL: https://issues.apache.org/jira/browse/GROOVY-9432
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 3.0.0, 3.0.1
> Environment: Reproduced under both macOS (Groovy 3.0.1 installed
> manually and via MacPorts) and Debian (Groovy installed via SDKMAN).
>Reporter: Marc Simpson
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
> Attachments: image-2020-03-03-14-30-10-210.png
>
>
> (Issue originally raised as: https://github.com/remkop/picocli/issues/970)
> Consider the following minimal script:
> {noformat}
> @Grab('info.picocli:picocli:4.2.0')
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder()
> {noformat}
> Under Groovy 2.5.9, this runs without error; with 3.0.1, however, I see:
> {noformat}
> $ groovy cli.groovy
> Caught: java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> at cli.run(cli.groovy:4)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.ClassNotFoundException:
> picocli.CommandLine$ParameterException
> ... 4 more
> {noformat}
> The jar is definitely downloaded to {{~/.groovy/grapes}} and both versions of
> Groovy output
> {noformat}
> Resolving dependency: info.picocli#picocli;4.2.0 {default=[default]}
> Preparing to download artifact info.picocli#picocli;4.2.0!picocli.jar
> {noformat}
> when {{-Dgroovy.grape.report.downloads=true}} is supplied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9432) ClassNotFoundException when attempting to use Picocli via Grapes
[
https://issues.apache.org/jira/browse/GROOVY-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9432:
Fix Version/s: 3.0.4
> ClassNotFoundException when attempting to use Picocli via Grapes
>
>
> Key: GROOVY-9432
> URL: https://issues.apache.org/jira/browse/GROOVY-9432
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 3.0.0, 3.0.1
> Environment: Reproduced under both macOS (Groovy 3.0.1 installed
> manually and via MacPorts) and Debian (Groovy installed via SDKMAN).
>Reporter: Marc Simpson
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
> Attachments: image-2020-03-03-14-30-10-210.png
>
>
> (Issue originally raised as: https://github.com/remkop/picocli/issues/970)
> Consider the following minimal script:
> {noformat}
> @Grab('info.picocli:picocli:4.2.0')
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder()
> {noformat}
> Under Groovy 2.5.9, this runs without error; with 3.0.1, however, I see:
> {noformat}
> $ groovy cli.groovy
> Caught: java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> at cli.run(cli.groovy:4)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.ClassNotFoundException:
> picocli.CommandLine$ParameterException
> ... 4 more
> {noformat}
> The jar is definitely downloaded to {{~/.groovy/grapes}} and both versions of
> Groovy output
> {noformat}
> Resolving dependency: info.picocli#picocli;4.2.0 {default=[default]}
> Preparing to download artifact info.picocli#picocli;4.2.0!picocli.jar
> {noformat}
> when {{-Dgroovy.grape.report.downloads=true}} is supplied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9531) Improve CliBuilder docs for Groovy 3.0
[
https://issues.apache.org/jira/browse/GROOVY-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9531:
Fix Version/s: 2.5.12
> Improve CliBuilder docs for Groovy 3.0
> --
>
> Key: GROOVY-9531
> URL: https://issues.apache.org/jira/browse/GROOVY-9531
> Project: Groovy
> Issue Type: Documentation
> Components: command line processing
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> The [CliBuilder section|[http://groovy-lang.org/dsls.html#_clibuilder]] of
> the Domain-Specific Languages page has some language that is outdated since
> the Groovy 3.0 release.
> Current:
> {quote}
> The groovy.util version points to the commons-cli version for backwards
> compatibility but will be removed in a future version of Groovy.
> {quote}
> I propose to change this to:
> {quote}
> The groovy.util version in Groovy 2.5 points to the commons-cli version for
> backwards compatibility but has been removed in Groovy 3.0.
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-9519:
Fix Version/s: 2.5.12
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097012#comment-17097012
]
Remko Popma commented on GROOVY-9528:
-
I cherry-picked your new test (thanks again for that!) to 2_5_x as well.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097009#comment-17097009
]
Remko Popma commented on GROOVY-9519:
-
Also added to the 2_5_x branch, except for the changes to
{{groovy.cli.internal.CliBuilderInternal}} (which does not exist in this
branch).
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9432) ClassNotFoundException when attempting to use Picocli via Grapes
[
https://issues.apache.org/jira/browse/GROOVY-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097004#comment-17097004
]
Remko Popma commented on GROOVY-9432:
-
I am adding the following to the (bottom of the) {{CliBuilder}} section of the
[Domain Specific Languages page|http://groovy-lang.org/dsls.html#_clibuilder].
{quote}
h4. Controlling the Picocli version
If necessary, you can use the {{@Grab}} annotation to control the version of
picocli to use in {{CliBuilder}}.
{code}
@GrabConfig(systemClassLoader=true)
@Grab('info.picocli:picocli:4.2.0')
import groovy.cli.picocli.CliBuilder
def cli = new CliBuilder()
{code}
{quote}
[~marcs]: do you think this is sufficient?
[~paulk]: I committed this to the master and 3_0_x branches. Should I also add
it to 2_5_x ?
> ClassNotFoundException when attempting to use Picocli via Grapes
>
>
> Key: GROOVY-9432
> URL: https://issues.apache.org/jira/browse/GROOVY-9432
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 3.0.0, 3.0.1
> Environment: Reproduced under both macOS (Groovy 3.0.1 installed
> manually and via MacPorts) and Debian (Groovy installed via SDKMAN).
>Reporter: Marc Simpson
>Assignee: Remko Popma
>Priority: Major
> Attachments: image-2020-03-03-14-30-10-210.png
>
>
> (Issue originally raised as: https://github.com/remkop/picocli/issues/970)
> Consider the following minimal script:
> {noformat}
> @Grab('info.picocli:picocli:4.2.0')
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder()
> {noformat}
> Under Groovy 2.5.9, this runs without error; with 3.0.1, however, I see:
> {noformat}
> $ groovy cli.groovy
> Caught: java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> at cli.run(cli.groovy:4)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.ClassNotFoundException:
> picocli.CommandLine$ParameterException
> ... 4 more
> {noformat}
> The jar is definitely downloaded to {{~/.groovy/grapes}} and both versions of
> Groovy output
> {noformat}
> Resolving dependency: info.picocli#picocli;4.2.0 {default=[default]}
> Preparing to download artifact info.picocli#picocli;4.2.0!picocli.jar
> {noformat}
> when {{-Dgroovy.grape.report.downloads=true}} is supplied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096516#comment-17096516
]
Remko Popma commented on GROOVY-9528:
-
Thank you for adding the test.
Also thank you for the heads up on the branch. Tomorrow I’ll double check the
other commits I made recently.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4, 2.5.12
>
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9432) ClassNotFoundException when attempting to use Picocli via Grapes
[
https://issues.apache.org/jira/browse/GROOVY-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned GROOVY-9432:
---
Assignee: Remko Popma
> ClassNotFoundException when attempting to use Picocli via Grapes
>
>
> Key: GROOVY-9432
> URL: https://issues.apache.org/jira/browse/GROOVY-9432
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 3.0.0, 3.0.1
> Environment: Reproduced under both macOS (Groovy 3.0.1 installed
> manually and via MacPorts) and Debian (Groovy installed via SDKMAN).
>Reporter: Marc Simpson
>Assignee: Remko Popma
>Priority: Major
> Attachments: image-2020-03-03-14-30-10-210.png
>
>
> (Issue originally raised as: https://github.com/remkop/picocli/issues/970)
> Consider the following minimal script:
> {noformat}
> @Grab('info.picocli:picocli:4.2.0')
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder()
> {noformat}
> Under Groovy 2.5.9, this runs without error; with 3.0.1, however, I see:
> {noformat}
> $ groovy cli.groovy
> Caught: java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> at cli.run(cli.groovy:4)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.ClassNotFoundException:
> picocli.CommandLine$ParameterException
> ... 4 more
> {noformat}
> The jar is definitely downloaded to {{~/.groovy/grapes}} and both versions of
> Groovy output
> {noformat}
> Resolving dependency: info.picocli#picocli;4.2.0 {default=[default]}
> Preparing to download artifact info.picocli#picocli;4.2.0!picocli.jar
> {noformat}
> when {{-Dgroovy.grape.report.downloads=true}} is supplied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-9519.
-
Fix Version/s: 3.0.4
Resolution: Fixed
Fixed in master and the 3.0.x branch.
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095101#comment-17095101
]
Remko Popma commented on GROOVY-9519:
-
Found it: [https://groovy.apache.org/buildstatus.html]
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095089#comment-17095089
]
Remko Popma commented on GROOVY-9519:
-
I added a failing test. Paul, could you point me to the CI server, so I can
verify that this test actually fails (and later that my fix makes the test
pass)?
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned GROOVY-9519:
---
Assignee: Remko Popma
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-9528.
-
Fix Version/s: 3.0.4
Resolution: Fixed
Fixed in master.
Will cherry-pick the subsection title change to the 3.0.x branch and 2.6.x
branch in a bit.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095068#comment-17095068
]
Remko Popma commented on GROOVY-9528:
-
Understood. Thanks for checking. I will push that change in a bit.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned GROOVY-9528:
---
Assignee: Remko Popma
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Assignee: Remko Popma
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095044#comment-17095044
]
Remko Popma commented on GROOVY-9528:
-
The [New property: parser|http://groovy-lang.org/dsls.html#_picocli] subsection
of the "Picocli" section of "Advanced CLI Usage" in
doc\core-domain-specific-languages.adoc now looks like this:
*New property: parser*
The {{parser}} property gives access to the picocli {{ParserSpec}} object that
can be used to customize the parser behavior.
This can be useful when the {{CliBuilder}} options to control the parser are
not fine-grained enough. For example, for backward compatibility with the
Commons CLI implementation of {{CliBuilder}}, by default {{CliBuilder}} stops
looking for options when an unknown option is encountered, and subsequent
command line arguments are treated as positional parameters. {{CliBuilder}}
provides a {{stopAtNonOption}} property, and by setting this to {{false}} you
can make the parser more strict, so an unknown option results in {{error:
Unknown option: '-x'}}.
But what if you want to treat unknown options as positional parameters, and
still process subsequent command line arguments as options?
This can be accomplished with the {{parser}} property. For example:
{code:java}
def cli = new CliBuilder()
cli.parser.stopAtPositional(false)
cli.parser.unmatchedOptionsArePositionalParams(true)
// ...
def opts = cli.parse(args)
// ...
{code}
See the
[documentation|http://picocli.info/apidocs/picocli/CommandLine.Model.ParserSpec.html]
for details.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9531) Improve CliBuilder docs for Groovy 3.0
[
https://issues.apache.org/jira/browse/GROOVY-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-9531.
-
Resolution: Fixed
Fixed in commit 152930df.
> Improve CliBuilder docs for Groovy 3.0
> --
>
> Key: GROOVY-9531
> URL: https://issues.apache.org/jira/browse/GROOVY-9531
> Project: Groovy
> Issue Type: Documentation
> Components: command line processing
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.4
>
>
> The [CliBuilder section|[http://groovy-lang.org/dsls.html#_clibuilder]] of
> the Domain-Specific Languages page has some language that is outdated since
> the Groovy 3.0 release.
> Current:
> {quote}
> The groovy.util version points to the commons-cli version for backwards
> compatibility but will be removed in a future version of Groovy.
> {quote}
> I propose to change this to:
> {quote}
> The groovy.util version in Groovy 2.5 points to the commons-cli version for
> backwards compatibility but has been removed in Groovy 3.0.
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9531) Improve CliBuilder docs for Groovy 3.0
Remko Popma created GROOVY-9531:
---
Summary: Improve CliBuilder docs for Groovy 3.0
Key: GROOVY-9531
URL: https://issues.apache.org/jira/browse/GROOVY-9531
Project: Groovy
Issue Type: Documentation
Components: command line processing
Affects Versions: 3.0.3, 3.0.2, 3.0.1, 3.0.0
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 3.0.4
The [CliBuilder section|[http://groovy-lang.org/dsls.html#_clibuilder]] of the
Domain-Specific Languages page has some language that is outdated since the
Groovy 3.0 release.
Current:
{quote}
The groovy.util version points to the commons-cli version for backwards
compatibility but will be removed in a future version of Groovy.
{quote}
I propose to change this to:
{quote}
The groovy.util version in Groovy 2.5 points to the commons-cli version for
backwards compatibility but has been removed in Groovy 3.0.
{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094948#comment-17094948
]
Remko Popma commented on GROOVY-9528:
-
Yes, that is what I was thinking too. Thanks for confirming.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9519) CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean if default value is applied
[
https://issues.apache.org/jira/browse/GROOVY-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094934#comment-17094934
]
Remko Popma commented on GROOVY-9519:
-
I have trouble building the Groovy project, so investigating with println...
If I add this to your script:
{code}
println(opts.i.getClass())
println(opts.i)
println()
println(opts.parseResult.matchedOptions())
println("hasMatchedOption=" + opts.parseResult.hasMatchedOption("i"))
println("findOption[i]=" + opts.parseResult.commandSpec().findOption("i"))
println("findOption[i].value=" +
opts.parseResult.commandSpec().findOption("i").value)
// Need to explicitely convert if default value applies
// ...
{code}
I see the following output:
{code}
class java.lang.Boolean
false
[]
hasMatchedOption=false
findOption[i]=option --intTest
findOption[i].value=0
{code}
Looking at the source code for {{groovy.cli.picocli.OptionAccessor}}, this is
the relevant snippet:
{code}
def getProperty(String name) {
if (name == 'parseResult') { return parseResult }
if (parseResult.hasMatchedOption(name)) { // false, skipping...
//...
}
if (parseResult.commandSpec().findOption(name)) { // requested option
was not matched: return its default
def option = parseResult.commandSpec().findOption(name)
def result = option.value
return result ? result : false
}
// we don't get here, skipping...
false
}
{code}
So, the option is found correctly, and its default value is found correctly.
However, this default value is zero, and because of Groovy truthiness, ` 0 ? 0
: false` returns `false`.
(This is why the problem does not occur when using a different default value
like 123.)
I am thinking that this code needs to check if the user specified a type, and
only rely on Groovy truthiness if no type was specified...
{code}
def option = parseResult.commandSpec().findOption(name)
def result = option.value
Class userSpecifiedType = savedTypeOptions[name]?.type
if (userSpecifiedType && Boolean != userSpecifiedType) { return
result }
return result ? result : false
{code}
Thoughts?
> CLIBuilder: Option with "type: Integer, defaultValue '0'" results in Boolean
> if default value is applied
>
>
> Key: GROOVY-9519
> URL: https://issues.apache.org/jira/browse/GROOVY-9519
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: WIndows/Linux
>Reporter: Dirk Heinrichs
>Priority: Major
>
> When using an option with {{type: Integer}} and {{defaultValue: '0'}} the
> resulting variable is of type Boolean if the option is not specified on the
> command line. Here's a little Groovy program to demonstrate the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.i(type: Integer, longOpt: 'intTest', required: false, args: 1,
> defaultValue: '0', 'Testing integer with default value 0')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }
> println(opts.i.getClass())
> println(opts.i)
> // Need to explicitely convert if default value applies
> def i = (opts.i instanceof Boolean ? 0 : opts.i)
> println(i.getClass())
> println(i){code}
> Executing this w/o providing {{-i}} prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy
> class java.lang.Boolean
> false
> class java.lang.Integer
> 0{code}
> But if {{-i}} IS provided (even with the same value as the default), it
> correctly prints:
> {code}% ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -i 0
> class java.lang.Integer
> 0
> class java.lang.Integer
> 0{code}
> I would expect the type of {{opts.i}} to be Integer in both cases.
> NOTE: I've opened the same for PicoCLI, since I wasn't sure where it belongs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094935#comment-17094935
]
Remko Popma commented on GROOVY-9528:
-
I will update the docs.
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094409#comment-17094409
]
Remko Popma commented on GROOVY-9528:
-
The {{stopAtNonOption}} property is meant for backward compatibility with the
Commons CLI implementation of CliBuilder. Note that the javadoc on the Commons
CLI implementation is a bit vague.
In the picocli implementation, it is implemented as follows:
{code}
void setStopAtNonOption(boolean stopAtNonOption) {
this.stopAtNonOption = stopAtNonOption
parser.stopAtPositional(stopAtNonOption)
parser.unmatchedOptionsArePositionalParams(stopAtNonOption)
}
{code}
[~dheinric] has a point that the current default behavior can be
counterintuitive.
One idea is to change the implementation to this:
{code}
void setStopAtNonOption(boolean stopAtNonOption) {
this.stopAtNonOption = stopAtNonOption
parser.unmatchedOptionsArePositionalParams(stopAtNonOption)
}
{code}
This way, unrecognized options would be treated as positional parameters, but
any subsequent known options would be recognized as such (and would not be
treated as positional parameters).
Thoughts?
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9528) CLIBuilder: "error: Missing required options" when unknown options are provided
[
https://issues.apache.org/jira/browse/GROOVY-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093994#comment-17093994
]
Remko Popma commented on GROOVY-9528:
-
Thank you [~paulk]!
[~dheinric], is any further action required on this ticket?
> CLIBuilder: "error: Missing required options" when unknown options are
> provided
> ---
>
> Key: GROOVY-9528
> URL: https://issues.apache.org/jira/browse/GROOVY-9528
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 3.0.2
> Environment: Linux/Windows
>Reporter: Dirk Heinrichs
>Priority: Major
>
> When passing an additional option to a script that doesn't know about this
> option, I get an error message about "missing required options", listing all
> required options that follow the unkown option.
> The following example code reproduces the issue:
> {code:java}
> @Grab('info.picocli:picocli-groovy:4.2.0')
> @GrabConfig(systemClassLoader=true)
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder(name: 'cliTest.groovy')
> cli.h(type: Boolean, longOpt: 'help', usageHelp: true, required: false, 'Show
> usage information')
> cli.a(type: String, longOpt: 'optA', required: true, args: 1, 'Option a
> (required)')
> cli.b(type: String, longOpt: 'optB', required: true, args: 1, 'Option b
> (required)')
> // NOTE: No "-c|--optC" here
> cli.d(type: String, longOpt: 'optD', required: true, args: 1, 'Option d
> (required)')
> cli.e(type: String, longOpt: 'optE', required: true, args: 1, 'Option e
> (required)')
> cli.f(type: String, longOpt: 'optF', required: false, args: 1, 'Option f
> (optional)')
> def opts = cli.parse(args)
> opts || System.exit(1)
> if(opts.h) {
> cli.usage()
> System.exit(0)
> }{code}
> When invoked with an additional option, '-c C' for example, it produces the
> following, misleading output:
> {code:java}
> % ~/tmp/groovy-3.0.2/bin/groovy ./cliTest.groovy -a A -b B -c C -d D -e E
> error: Missing required options [--optD=PARAM, --optE=PARAM]
> Usage: cliTest.groovy [-h] -a=PARAM -b=PARAM -d=PARAM -e=PARAM [-f=PARAM]
> -a, --optA=PARAM Option a (required)
> -b, --optB=PARAM Option b (required)
> -d, --optD=PARAM Option d (required)
> -e, --optE=PARAM Option e (required)
> -f, --optF=PARAM Option f (optional)
> -h, --help Show usage information{code}
> The list of missing options varies depending on where "-c C" is inserted.
> There's no error when it's the last one.
> I would expect it to either ignore the addtional option in all cases or emit
> an error message about an unknown option. But in no case should it error out
> because of missing required options when there are none missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9432) ClassNotFoundException when attempting to use Picocli via Grapes
[
https://issues.apache.org/jira/browse/GROOVY-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054257#comment-17054257
]
Remko Popma commented on GROOVY-9432:
-
[~marcs] has a point. How should users use {{CliBuilder}} in groovy scripts
from Groovy 3.0.1+?
The below does not work: ({{NoClassDefFoundError:
picocli/CommandLine$ParameterException}} in the {{CliBuilder constructor}})
{code}
@Grab('org.codehaus.groovy:groovy-cli-picocli:3.0.1')
import groovy.cli.picocli.CliBuilder
def cli = new CliBuilder()
{code}
I tried a few variations, the below is the only one I got to work... Is the
below the recommended way?
{code}
@GrabConfig(systemClassLoader=true)
@Grab('org.codehaus.groovy:groovy-cli-picocli:3.0.1')
@Grab('info.picocli:picocli:4.2.0')
import groovy.cli.picocli.CliBuilder
def cli = new CliBuilder()
println picocli.CommandLine.VERSION
{code}
If that is true, should we update the documentation for CliBuilder to clarify
this?
Note that I find [~marcs]'s point on the picocli documentation a bit confusing.
At no point does the picocli user manual mention {{CliBuilder}}, there is no
intention that {{@Grab('info.picocli:picocli:4.2.0')}} would work with
{{CliBuilder}}. So while I am happy to improve the picocli documentation as
well, I am not sure if/how.
> ClassNotFoundException when attempting to use Picocli via Grapes
>
>
> Key: GROOVY-9432
> URL: https://issues.apache.org/jira/browse/GROOVY-9432
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 3.0.0, 3.0.1
> Environment: Reproduced under both macOS (Groovy 3.0.1 installed
> manually and via MacPorts) and Debian (Groovy installed via SDKMAN).
>Reporter: Marc Simpson
>Priority: Major
> Attachments: image-2020-03-03-14-30-10-210.png
>
>
> (Issue originally raised as: https://github.com/remkop/picocli/issues/970)
> Consider the following minimal script:
> {noformat}
> @Grab('info.picocli:picocli:4.2.0')
> import groovy.cli.picocli.CliBuilder
> def cli = new CliBuilder()
> {noformat}
> Under Groovy 2.5.9, this runs without error; with 3.0.1, however, I see:
> {noformat}
> $ groovy cli.groovy
> Caught: java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> java.lang.NoClassDefFoundError: picocli/CommandLine$ParameterException
> at cli.run(cli.groovy:4)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.ClassNotFoundException:
> picocli.CommandLine$ParameterException
> ... 4 more
> {noformat}
> The jar is definitely downloaded to {{~/.groovy/grapes}} and both versions of
> Groovy output
> {noformat}
> Resolving dependency: info.picocli#picocli;4.2.0 {default=[default]}
> Preparing to download artifact info.picocli#picocli;4.2.0!picocli.jar
> {noformat}
> when {{-Dgroovy.grape.report.downloads=true}} is supplied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9202) Bump picocli to 4.0.1
[ https://issues.apache.org/jira/browse/GROOVY-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893238#comment-16893238 ] Remko Popma commented on GROOVY-9202: - Paul, thank you for finding and fixing that. I’ll raise an issue with jarjar (or link to this one if a ticket already exists). (Away from PC now.) Is there any work remaining on this? > Bump picocli to 4.0.1 > - > > Key: GROOVY-9202 > URL: https://issues.apache.org/jira/browse/GROOVY-9202 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.8, 3.0.0-beta-3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GROOVY-9202) Bump picocli to 4.0.1
[ https://issues.apache.org/jira/browse/GROOVY-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891424#comment-16891424 ] Remko Popma commented on GROOVY-9202: - Updated in commits 669127c9 (master) and 5c80e0da (2.5.x branch). > Bump picocli to 4.0.1 > - > > Key: GROOVY-9202 > URL: https://issues.apache.org/jira/browse/GROOVY-9202 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.8, 3.0.0-beta-3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (GROOVY-9202) Bump picocli to 4.0.1
[ https://issues.apache.org/jira/browse/GROOVY-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-9202. --- Resolution: Fixed > Bump picocli to 4.0.1 > - > > Key: GROOVY-9202 > URL: https://issues.apache.org/jira/browse/GROOVY-9202 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.8, 3.0.0-beta-3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GROOVY-9202) Bump picocli to 4.0.1
[ https://issues.apache.org/jira/browse/GROOVY-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated GROOVY-9202: Fix Version/s: 2.5.8 > Bump picocli to 4.0.1 > - > > Key: GROOVY-9202 > URL: https://issues.apache.org/jira/browse/GROOVY-9202 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.8, 3.0.0-beta-3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889920#comment-16889920
]
Remko Popma commented on GROOVY-9165:
-
Picocli 4.0 has been released and I can look at this this week.
This ticket is closed now , but are we okay with an alternative solution that
simply uses picocli directly instead of adding an internal CliBuilder?
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-beta-2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GROOVY-9202) Bump picocli to 4.0.1
[ https://issues.apache.org/jira/browse/GROOVY-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma reassigned GROOVY-9202: --- Assignee: Remko Popma > Bump picocli to 4.0.1 > - > > Key: GROOVY-9202 > URL: https://issues.apache.org/jira/browse/GROOVY-9202 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Remko Popma >Priority: Major > Fix For: 3.0.0-beta-3 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880229#comment-16880229
]
Remko Popma commented on GROOVY-9165:
-
I've had a chance to take a look at the changes.
I think we should just use plain picocli instead of an internal CliBuilder.
Some of the tools have been localized but picocli can do internationalization.
I can help with the changes but I want to work on releasing picocli 4.0 first.
After that I'd be happy to help migrate the 6 classes that currently use the
new internal CliBuilder to plain picocli on both master and the 2.5 branch.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-beta-2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880229#comment-16880229
]
Remko Popma edited comment on GROOVY-9165 at 7/8/19 11:29 AM:
--
I've had a chance to take a look at the changes.
I think we should just use plain picocli instead of an creating a new internal
CliBuilder. Some of the tools have been localized but picocli can do
internationalization. I can help with the changes but I want to work on
releasing picocli 4.0 first. After that I'd be happy to help migrate the 6
classes that currently use the new internal CliBuilder to plain picocli on both
master and the 2.5 branch.
was (Author: rem...@yahoo.com):
I've had a chance to take a look at the changes.
I think we should just use plain picocli instead of an internal CliBuilder.
Some of the tools have been localized but picocli can do internationalization.
I can help with the changes but I want to work on releasing picocli 4.0 first.
After that I'd be happy to help migrate the 6 classes that currently use the
new internal CliBuilder to plain picocli on both master and the 2.5 branch.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-beta-2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879849#comment-16879849
]
Remko Popma commented on GROOVY-9165:
-
Thanks for progressing this!
I’ve been focusing on getting the picocli 4.0 release out (1or 2 weeks left)
and was going to get back to this ticket after that.
I’ll try to take a look this week.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-beta-2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860475#comment-16860475
]
Remko Popma commented on GROOVY-9165:
-
Thanks for the clarification and the link.
Fixing GROOVY-4810 is ideal and would address the underlying problem but is
most complex. Your suggestion makes sense. Pity that it only solves the smaller
problem of {{@Grab}}-ing a specific picocli version.
I guess the commons-cli jar is included in the distro for backwards
compatibility to ensure that the default (deprecated)
{{groovy.util.CliBuilder}} works out of the box.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Priority: Major
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859660#comment-16859660
]
Remko Popma edited comment on GROOVY-9165 at 6/10/19 2:18 AM:
--
Not sure I understand: CliBuilder requires picocli to work. It does not work
with the embedded jarjar'ed version. The distribution contains the picocli jar
(and the commons-cli jar) so that Groovy apps using CliBuilder work out of the
box.
The problem is not that {{groovy.ui.GroovyMain}} uses picocli directly instead
of CliBuilder. {{GroovyMain}} and other places where picocli is used directly
actually have their imports renamed to {{groovyjarjarpicocli}} to use the
embedded one, so that is fine: there is no conflict with the version that the
script is trying to pull in with {{@Grab}}.
About LoaderConfiguration/GroovyStarter, I've started to think that it would
make sense to ensure that {{@Grab}}-ed dependencies come _first_ in the
classpath. That would be a generic way to allow all groovy scripts to specify
the exact version of any library, regardless of what is in the distribution.
Thoughts?
was (Author: rem...@yahoo.com):
Not sure I understand: CliBuilder requires picocli to work. It does not work
with the embedded jarjar'ed version. The distribution contains the picocli jar
(and the commons-cli jar) so that Groovy apps using CliBuilder work out of the
box.
The problem is not that {{groovy.ui.GroovyMain}} uses picocli directly instead
of CliBuilder. {{GroovyMain}} and other places where picocli is used directly
actually have their imports renamed to {{groovyjarjarpicocli}} to use the
embedded one, so that is fine: there is no conflict with the version that the
script is trying to pull in with {{@Grab}}.
About LoaderConfiguration, I've started to think that it would make sense to
ensure that {{@Grab}}-ed dependencies come _first_ in the classpath. That would
be a generic way to allow all groovy scripts to specify the exact version of
any library, regardless of what is in the distribution. Thoughts?
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Priority: Major
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859660#comment-16859660
]
Remko Popma commented on GROOVY-9165:
-
Not sure I understand: CliBuilder requires picocli to work. It does not work
with the embedded jarjar'ed version. The distribution contains the picocli jar
(and the commons-cli jar) so that Groovy apps using CliBuilder work out of the
box.
The problem is not that {{groovy.ui.GroovyMain}} uses picocli directly instead
of CliBuilder. {{GroovyMain}} and other places where picocli is used directly
actually have their imports renamed to {{groovyjarjarpicocli}} to use the
embedded one, so that is fine: there is no conflict with the version that the
script is trying to pull in with {{@Grab}}.
About LoaderConfiguration, I've started to think that it would make sense to
ensure that {{@Grab}}-ed dependencies come _first_ in the classpath. That would
be a generic way to allow all groovy scripts to specify the exact version of
any library, regardless of what is in the distribution. Thoughts?
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Priority: Major
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859407#comment-16859407
]
Remko Popma commented on GROOVY-9165:
-
You are right: it is using the jar in the libs folder:
{code}
package picocli.examples
@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
@GrabExclude('org.codehaus.groovy:groovy-all')
@picocli.groovy.PicocliScript
@picocli.CommandLine.Command
import picocli.CommandLine
println "Groovy version ${GroovySystem.version}"
println "Picocli version $CommandLine.VERSION"
println "picocli location:
${CommandLine.class.getResource("/picocli/CommandLine.class")}"
{code}
prints out:
{code}
Groovy version 2.5.7
Picocli version 3.9.5
picocli location:
jar:file:/C:/apps/groovy-2.5.7/bin/../lib/picocli-3.9.5.jar!/picocli/CommandLine.class
{code}
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Priority: Major
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859407#comment-16859407
]
Remko Popma edited comment on GROOVY-9165 at 6/9/19 9:03 AM:
-
You are right: it is using the jar in the libs folder:
{code}
package picocli.examples
@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
@GrabExclude('org.codehaus.groovy:groovy-all')
@picocli.groovy.PicocliScript
@picocli.CommandLine.Command
import picocli.CommandLine
println "Groovy version ${GroovySystem.version}"
println "Picocli version $CommandLine.VERSION"
println "picocli location:
${CommandLine.class.getResource(\"/picocli/CommandLine.class\")}"
{code}
prints out:
{code}
Groovy version 2.5.7
Picocli version 3.9.5
picocli location:
jar:file:/C:/apps/groovy-2.5.7/bin/../lib/picocli-3.9.5.jar!/picocli/CommandLine.class
{code}
was (Author: rem...@yahoo.com):
You are right: it is using the jar in the libs folder:
{code}
package picocli.examples
@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
@GrabExclude('org.codehaus.groovy:groovy-all')
@picocli.groovy.PicocliScript
@picocli.CommandLine.Command
import picocli.CommandLine
println "Groovy version ${GroovySystem.version}"
println "Picocli version $CommandLine.VERSION"
println "picocli location:
${CommandLine.class.getResource("/picocli/CommandLine.class")}"
{code}
prints out:
{code}
Groovy version 2.5.7
Picocli version 3.9.5
picocli location:
jar:file:/C:/apps/groovy-2.5.7/bin/../lib/picocli-3.9.5.jar!/picocli/CommandLine.class
{code}
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Priority: Major
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859328#comment-16859328
]
Remko Popma commented on GROOVY-9165:
-
So it looks like we already catered for this but it is not working somehow.
Looking at the {{groovy.ui.GroovyMain}} source, it is currently using picocli
directly (not CliBuilder). This is good. If I understand correctly, our
{{gradle/assemble.gradle}} replaces all {{import picocli.\*}} statements in all
Groovy classes with {{import groovyjarjarpicocli.@1}} (except the
{{untouchedFiles}}, which include {{groovy/cli/picocli/CliBuilder\*.class}}).
To confirm, I looked in the {{groovy-2.5.7.jar}}, and decompiled its
{{groovy/ui/GroovyMain.class}}, and it correctly imports
{{groovyjarjarpicocli.CommandLine}}. So that all looks fine, but there is still
an issue when running a script that grabs picocli...
Hmm... I will investigate further.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Priority: Major
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-9165) Grape cannot pull in picocli
Remko Popma created GROOVY-9165:
---
Summary: Grape cannot pull in picocli
Key: GROOVY-9165
URL: https://issues.apache.org/jira/browse/GROOVY-9165
Project: Groovy
Issue Type: Improvement
Components: Grape, groovy-runtime
Affects Versions: 2.5.7, 2.5.6, 2.5.5, 2.5.4, 2.5.3, 2.5.2, 2.5.1, 2.5.0
Reporter: Remko Popma
If I try to run a Groovy script I am unable to pull in a newer version of
picocli via {{@Grab}}:
{code:groovy}
@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
@GrabExclude('org.codehaus.groovy:groovy-all')
@picocli.groovy.PicocliScript
@picocli.CommandLine.Command
import picocli.CommandLine
println "Groovy version ${GroovySystem.version}"
println "Picocli version $CommandLine.VERSION"
{code}
Depending on the Groovy version, this prints
{code}
Groovy version 2.5.0
Picocli version 3.0.2
{code}
or
{code}
Groovy version 2.5.7
Picocli version 3.9.5
{code}
So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
scripts, itself uses picocli to parse the command line parameters.
Unfortunately, this means that Groovy script authors cannot control the picocli
version used by their scripts.
Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GROOVY-9016) picocli-based CliBuilder can be tricked into greedily consuming option as an arg
[
https://issues.apache.org/jira/browse/GROOVY-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned GROOVY-9016:
---
Assignee: Remko Popma
> picocli-based CliBuilder can be tricked into greedily consuming option as an
> arg
>
>
> Key: GROOVY-9016
> URL: https://issues.apache.org/jira/browse/GROOVY-9016
> Project: Groovy
> Issue Type: Bug
> Components: command line processing
>Affects Versions: 2.5.6
> Environment: >>First encountered<<
> Groovy 2.4.15 - no bug
> Groovy 2.5.6 - bug
> Win 8.1 Pro
> Zulu OpenJDK 1.8.0_202
> >>Minimal replication<<
> Groovy 2.4.8 (distro package) - no bug
> OpenJDK 1.8.0_181 (distro package)
> Debian 9/Stretch
> groovy:2.5.6-jre8-alpine Docker image - bug
> OpenJdk 1.8.0_191 (in image)
> Debian 9/Stretch + Alpine 8 (in image)
>Reporter: Brian Ray
>Assignee: Remko Popma
>Priority: Minor
>
> Stumbled across this edge case upgrading from 2.4.x to 2.5.6. Given the
> following {{CliBuilder}} based script,
> {code:java}
> final cli = new CliBuilder()
> cli.with {
> f(
> longOpt: "firstOpt",
> "first option",
> required: false,
> args: 1,
> argName: "firstOpt",
> )
> }
> final opts = cli.parse(args)
> println """
> firstOpt=$opts.firstOpt
> args=${ opts.arguments() }
> """
> {code}
> Passing an option value containing the character combo {{+=}} can trigger
> greedy assignment to args. Here is the pre-2.5 behavior.
> {noformat}
> $ ~/cli_greedy_arg.groovy -f+= bat
> firstOpt=+=
> args=[bat]
> $ ~/cli_greedy_arg.groovy -f'+=' bat
> firstOpt=+=
> args=[bat]
> $ ~/cli_greedy_arg.groovy -f"+=" bat
> firstOpt=+=
> args=[bat]
> $ ~/cli_greedy_arg.groovy -f="+=" bat
> firstOpt==+=
> args=[bat]
> {noformat}
> That odd option value is captured properly each time.
> Bumping up to 2.5.6 that option value tricks picocli (I'm guessing) into
> consuming the opt value as an arg in three out of four attempts.
> {noformat}
> $ docker run --rm -v "$PWD":/home/groovy/scripts -w /home/groovy/scripts
> groovy:2.5.6-jre8
> -alpine groovy cli_greedy_arg.groovy -f+= bat
> firstOpt=false
> args=[-f+=, bat]
> $ docker run --rm -v "$PWD":/home/groovy/scripts -w /home/groovy/scripts
> groovy:2.5.6-jre8
> -alpine groovy cli_greedy_arg.groovy -f'+=' bat
> firstOpt=false
> args=[-f+=, bat]
> $ docker run --rm -v "$PWD":/home/groovy/scripts -w /home/groovy/scripts
> groovy:2.5.6-jre8
> -alpine groovy cli_greedy_arg.groovy -f"+=" bat
> firstOpt=false
> args=[-f+=, bat]
> $ docker run --rm -v "$PWD":/home/groovy/scripts -w /home/groovy/scripts
> groovy:2.5.6-jre8
> -alpine groovy cli_greedy_arg.groovy -f="+=" bat
> firstOpt=+=
> args=[bat]
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9012) grape resolve command throws MissingPropertyException: No such property: arg
[
https://issues.apache.org/jira/browse/GROOVY-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785438#comment-16785438
]
Remko Popma commented on GROOVY-9012:
-
[~pzygielo]
[confirmed|https://issues.apache.org/jira/browse/GROOVY-8577?focusedCommentId=16785412=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16785412]
the grape resolve command works as expected after the fix.
> grape resolve command throws MissingPropertyException: No such property: arg
>
>
> Key: GROOVY-9012
> URL: https://issues.apache.org/jira/browse/GROOVY-9012
> Project: Groovy
> Issue Type: Bug
> Components: command line processing, Grape
>Affects Versions: 2.5.6
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.5.7
>
>
> From the user mailing list:
> {code}
> $ groovy -v
> Groovy Version: 2.5.6 JVM: 1.8.0_77 Vendor: Oracle Corporation OS: Mac OS X
> {code}
>
> {code}
> $ grape list | grep jcraft
> com.jcraft jsch [0.1.42, 0.1.54, 0.1.55, 0.1.46, 0.1.53]
> {code}
>
> {code}
> $ grape resolve com.jcraft jsch 0.1.53
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:110)
> at
> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
> Caused by: groovyjarjarpicocli.CommandLine$ExecutionException: Error while
> running command (org.codehaus.groovy.tools.GrapeMain$Resolve@609e8838):
> groovy.lang.MissingPropertyException: No such property: arg for class:
> org.codehaus.groovy.tools.GrapeMain
> at
> groovyjarjarpicocli.CommandLine.execute(CommandLine.java:1168)
> at
> groovyjarjarpicocli.CommandLine.access$800(CommandLine.java:141)
> at
> groovyjarjarpicocli.CommandLine$RunLast.handle(CommandLine.java:1367)
> at
> groovyjarjarpicocli.CommandLine$RunLast.handle(CommandLine.java:1335)
> at
> groovyjarjarpicocli.CommandLine$AbstractParseResultHandler.handleParseResult(CommandLine.java:1243)
> at
> groovyjarjarpicocli.CommandLine.parseWithHandlers(CommandLine.java:1526)
> at
> groovyjarjarpicocli.CommandLine.parseWithHandler(CommandLine.java:1465)
> at
> groovyjarjarpicocli.CommandLine$parseWithHandler$0.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:135)
> at
> org.codehaus.groovy.tools.GrapeMain.main(GrapeMain.groovy:72)
> ... 6 more
> Caused by: groovy.lang.MissingPropertyException: No such property: arg for
> class: org.codehaus.groovy.tools.GrapeMain
> at
> groovy.lang.MetaClassImpl.invokeStaticMissingProperty(MetaClassImpl.java:1021)
> at
> groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1866)
> at
> groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1842)
> at
> groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3797)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:193)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:468)
> at
> org.codehaus.groovy.tools.GrapeMain$Resolve.propertyMissing(GrapeMain.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
> at
> groovy.lang.MetaClassImpl.invokeMissingProperty(MetaClassImpl.java:889)
> at
> groovy.lang.MetaClassImpl$12.getProperty(MetaClassImpl.java:2016)
> at
>
[jira] [Commented] (GROOVY-8577) Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli
[ https://issues.apache.org/jira/browse/GROOVY-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785436#comment-16785436 ] Remko Popma commented on GROOVY-8577: - Great, thanks for the configuration! > Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli > - > > Key: GROOVY-8577 > URL: https://issues.apache.org/jira/browse/GROOVY-8577 > Project: Groovy > Issue Type: Improvement > Components: command line processing >Reporter: Remko Popma >Assignee: Paul King >Priority: Major > Fix For: 2.5.0-rc-3 > > > Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli as part of > GROOVY-8556. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8577) Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli
[ https://issues.apache.org/jira/browse/GROOVY-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16784912#comment-16784912 ] Remko Popma commented on GROOVY-8577: - [~pzygielo], yes, this migration caused the issue you are referring to. Please see GROOVY-9012 for details. The issue has been fixed in master and the GROOVY_25_X branch and will be included in the next 2.5.7 release. Can you please verify that the fix resolves your issue correctly? > Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli > - > > Key: GROOVY-8577 > URL: https://issues.apache.org/jira/browse/GROOVY-8577 > Project: Groovy > Issue Type: Improvement > Components: command line processing >Reporter: Remko Popma >Assignee: Paul King >Priority: Major > Fix For: 2.5.0-rc-3 > > > Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli as part of > GROOVY-8556. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-9012) grape resolve command throws MissingPropertyException: No such property: arg
[
https://issues.apache.org/jira/browse/GROOVY-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-9012.
-
Resolution: Fixed
Fixed in master and GROOVY_2_5_X branches.
Cause:
The resolve command implementation referred to a non-existing field 'arg'. This
bug was introduced during the migration to picocli.
The original implementation referred to both an {{arg}} property and the
{{args}} property, which is also incorrect, but less impact-full (it only means
that the validation to require at least 3 arguments is broken).
Please verify.
> grape resolve command throws MissingPropertyException: No such property: arg
>
>
> Key: GROOVY-9012
> URL: https://issues.apache.org/jira/browse/GROOVY-9012
> Project: Groovy
> Issue Type: Bug
> Components: command line processing, Grape
>Affects Versions: 2.5.6
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.5.7
>
>
> From the user mailing list:
> {code}
> $ groovy -v
> Groovy Version: 2.5.6 JVM: 1.8.0_77 Vendor: Oracle Corporation OS: Mac OS X
> {code}
>
> {code}
> $ grape list | grep jcraft
> com.jcraft jsch [0.1.42, 0.1.54, 0.1.55, 0.1.46, 0.1.53]
> {code}
>
> {code}
> $ grape resolve com.jcraft jsch 0.1.53
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:110)
> at
> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
> Caused by: groovyjarjarpicocli.CommandLine$ExecutionException: Error while
> running command (org.codehaus.groovy.tools.GrapeMain$Resolve@609e8838):
> groovy.lang.MissingPropertyException: No such property: arg for class:
> org.codehaus.groovy.tools.GrapeMain
> at
> groovyjarjarpicocli.CommandLine.execute(CommandLine.java:1168)
> at
> groovyjarjarpicocli.CommandLine.access$800(CommandLine.java:141)
> at
> groovyjarjarpicocli.CommandLine$RunLast.handle(CommandLine.java:1367)
> at
> groovyjarjarpicocli.CommandLine$RunLast.handle(CommandLine.java:1335)
> at
> groovyjarjarpicocli.CommandLine$AbstractParseResultHandler.handleParseResult(CommandLine.java:1243)
> at
> groovyjarjarpicocli.CommandLine.parseWithHandlers(CommandLine.java:1526)
> at
> groovyjarjarpicocli.CommandLine.parseWithHandler(CommandLine.java:1465)
> at
> groovyjarjarpicocli.CommandLine$parseWithHandler$0.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:135)
> at
> org.codehaus.groovy.tools.GrapeMain.main(GrapeMain.groovy:72)
> ... 6 more
> Caused by: groovy.lang.MissingPropertyException: No such property: arg for
> class: org.codehaus.groovy.tools.GrapeMain
> at
> groovy.lang.MetaClassImpl.invokeStaticMissingProperty(MetaClassImpl.java:1021)
> at
> groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1866)
> at
> groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1842)
> at
> groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3797)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:193)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:468)
> at
> org.codehaus.groovy.tools.GrapeMain$Resolve.propertyMissing(GrapeMain.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
> at
> groovy.lang.MetaClassImpl.invokeMissingProperty(MetaClassImpl.java:889)
> at
>
[jira] [Created] (GROOVY-9012) grape resolve command throws MissingPropertyException: No such property: arg
Remko Popma created GROOVY-9012:
---
Summary: grape resolve command throws MissingPropertyException: No
such property: arg
Key: GROOVY-9012
URL: https://issues.apache.org/jira/browse/GROOVY-9012
Project: Groovy
Issue Type: Bug
Components: command line processing, Grape
Affects Versions: 2.5.6
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.5.7
>From the user mailing list:
{code}
$ groovy -v
Groovy Version: 2.5.6 JVM: 1.8.0_77 Vendor: Oracle Corporation OS: Mac OS X
{code}
{code}
$ grape list | grep jcraft
com.jcraft jsch [0.1.42, 0.1.54, 0.1.55, 0.1.46, 0.1.53]
{code}
{code}
$ grape resolve com.jcraft jsch 0.1.53
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:110)
at
org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
Caused by: groovyjarjarpicocli.CommandLine$ExecutionException: Error while
running command (org.codehaus.groovy.tools.GrapeMain$Resolve@609e8838):
groovy.lang.MissingPropertyException: No such property: arg for class:
org.codehaus.groovy.tools.GrapeMain
at
groovyjarjarpicocli.CommandLine.execute(CommandLine.java:1168)
at
groovyjarjarpicocli.CommandLine.access$800(CommandLine.java:141)
at
groovyjarjarpicocli.CommandLine$RunLast.handle(CommandLine.java:1367)
at
groovyjarjarpicocli.CommandLine$RunLast.handle(CommandLine.java:1335)
at
groovyjarjarpicocli.CommandLine$AbstractParseResultHandler.handleParseResult(CommandLine.java:1243)
at
groovyjarjarpicocli.CommandLine.parseWithHandlers(CommandLine.java:1526)
at
groovyjarjarpicocli.CommandLine.parseWithHandler(CommandLine.java:1465)
at
groovyjarjarpicocli.CommandLine$parseWithHandler$0.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:135)
at org.codehaus.groovy.tools.GrapeMain.main(GrapeMain.groovy:72)
... 6 more
Caused by: groovy.lang.MissingPropertyException: No such property: arg for
class: org.codehaus.groovy.tools.GrapeMain
at
groovy.lang.MetaClassImpl.invokeStaticMissingProperty(MetaClassImpl.java:1021)
at
groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1866)
at
groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1842)
at
groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3797)
at
org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:193)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:468)
at
org.codehaus.groovy.tools.GrapeMain$Resolve.propertyMissing(GrapeMain.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
at
groovy.lang.MetaClassImpl.invokeMissingProperty(MetaClassImpl.java:889)
at
groovy.lang.MetaClassImpl$12.getProperty(MetaClassImpl.java:2016)
at
org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.getProperty(GetEffectivePogoPropertySite.java:85)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:309)
at
org.codehaus.groovy.tools.GrapeMain$Resolve.run(GrapeMain.groovy:235)
at
groovyjarjarpicocli.CommandLine.execute(CommandLine.java:1160)
... 17 more
{code}
{code}
$ grape help resolve
Enumerates the jars used by a grape
Usage: grape resolve [-adhisv] ( )+
Prints the file locations of the jars representing the artifcats for the
specified module(s) and the respective transitive dependencies.
Parameters:
Which module group the module comes from. Translates
[jira] [Closed] (GROOVY-9001) Bump picocli to 3.9.5 from 3.9.3
[ https://issues.apache.org/jira/browse/GROOVY-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-9001. --- > Bump picocli to 3.9.5 from 3.9.3 > > > Key: GROOVY-9001 > URL: https://issues.apache.org/jira/browse/GROOVY-9001 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.6 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.7 > > > This upgrade is important: native code included in jansi-1.14 (included in > Gradle 4.5.x) seems to have a bug that can crash the JVM. > (Version details: RHEL 3.10.0-327.44.2.el7.x86_64 on Java 1.8.0_112-b15 > Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)). > Picocli 3.9.5 will _only_ load jansi classes when running on Windows. Picocli > versions 3.9.0 to 3.9.4 may load jansi classes when running on non-Windows > platforms and are vulnerable to this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-9001) Bump picocli to 3.9.5 from 3.9.3
Remko Popma created GROOVY-9001: --- Summary: Bump picocli to 3.9.5 from 3.9.3 Key: GROOVY-9001 URL: https://issues.apache.org/jira/browse/GROOVY-9001 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.6 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.7 This upgrade is important: native code included in jansi-1.14 (included in Gradle 4.5.x) seems to have a bug that can crash the JVM. (Version details: RHEL 3.10.0-327.44.2.el7.x86_64 on Java 1.8.0_112-b15 Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)). Picocli 3.9.5 will _only_ load jansi classes when running on Windows. Picocli versions 3.9.0 to 3.9.4 may load jansi classes when running on non-Windows platforms and are vulnerable to this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8975) GroovyCastException on the result of CliBuilder.parseFromSpec
[
https://issues.apache.org/jira/browse/GROOVY-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771591#comment-16771591
]
Remko Popma commented on GROOVY-8975:
-
Thank you for taking care of this, Paul!
> GroovyCastException on the result of CliBuilder.parseFromSpec
> -
>
> Key: GROOVY-8975
> URL: https://issues.apache.org/jira/browse/GROOVY-8975
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.5
>Reporter: Mauro Molinari
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-5, 2.5.7
>
> Attachments: GROOVY-8975.zip, TestGroovy8975.zip
>
>
> I'm trying to follow the tutorial about the use of CliBuilder in Groovy with
> Groovy 2.5.5. Copying the code at [Annotating methods of an
> interface|https://github.com/remkop/picocli/wiki/Groovy-2.5-CliBuilder-Renewal#annotating-methods-of-an-interface]
> paragraph, at runtime I have the following Exception:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20)Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20){noformat}
> The exception occurs at this line:
> {{IHello hello = cli.parseFromSpec(IHello, argz)}}
> The exception goes away (and all works fine) if I replace it with:
> {{def hello = cli.parseFromSpec(IHello, argz)}}
> I tried to downgrade Groovy down to version 2.5.0 and I always get the
> exception. So this really puzzles me, since the mentioned tutorial is quite
> simple and straight to follow...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8975) GroovyCastException on the result of CliBuilder.parseFromSpec
[
https://issues.apache.org/jira/browse/GROOVY-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770932#comment-16770932
]
Remko Popma commented on GROOVY-8975:
-
Hi Paul, thanks for looking into this! I'm a bit out of my depth here.
Should we change {{CliBuilder#parseFromSpec}} to the below?
{code}
-cliOptions as T
+DefaultGroovyMethods.asType(cliOptions, optionsClass)
{code}
> GroovyCastException on the result of CliBuilder.parseFromSpec
> -
>
> Key: GROOVY-8975
> URL: https://issues.apache.org/jira/browse/GROOVY-8975
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.5
>Reporter: Mauro Molinari
>Assignee: Remko Popma
>Priority: Major
> Attachments: GROOVY-8975.zip
>
>
> I'm trying to follow the tutorial about the use of CliBuilder in Groovy with
> Groovy 2.5.5. Copying the code at [Annotating methods of an
> interface|https://github.com/remkop/picocli/wiki/Groovy-2.5-CliBuilder-Renewal#annotating-methods-of-an-interface]
> paragraph, at runtime I have the following Exception:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20)Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(DcsServizi2Sdi.groovy:20){noformat}
> The exception occurs at this line:
> {{IHello hello = cli.parseFromSpec(IHello, argz)}}
> The exception goes away (and all works fine) if I replace it with:
> {{def hello = cli.parseFromSpec(IHello, argz)}}
> I tried to downgrade Groovy down to version 2.5.0 and I always get the
> exception. So this really puzzles me, since the mentioned tutorial is quite
> simple and straight to follow...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8975) GroovyCastException on the result of CliBuilder.parseFromSpec
[
https://issues.apache.org/jira/browse/GROOVY-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770353#comment-16770353
]
Remko Popma commented on GROOVY-8975:
-
I was unable to reproduce the problem. I attached the project I created to
verify this. This worked as expected in my IDEA (IntelliJ) and on the command
line. You can try if this project works. On the command line, the minimum
classpath to run the example is the below (assuming the jars are in the current
directory):
{code}
java -cp
out\production\classes;groovy-2.5.6.jar;groovy-cli-picocli-2.5.6.jar;picocli-3.9.2.jar
pkg.App
{code}
I suspect it may be a problem in your environment, and I remember seeing a
similar error at some point when I was working on CliBuilder. I don't remember
what I did to fix it...
Could it be there are multiple versions of Groovy in the classpath?
> GroovyCastException on the result of CliBuilder.parseFromSpec
> -
>
> Key: GROOVY-8975
> URL: https://issues.apache.org/jira/browse/GROOVY-8975
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.5
>Reporter: Mauro Molinari
>Assignee: Remko Popma
>Priority: Major
> Attachments: GROOVY-8975.zip
>
>
> I'm trying to follow the tutorial about the use of CliBuilder in Groovy with
> Groovy 2.5.5. Copying the code at [Annotating methods of an
> interface|https://github.com/remkop/picocli/wiki/Groovy-2.5-CliBuilder-Renewal#annotating-methods-of-an-interface]
> paragraph, at runtime I have the following Exception:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20)Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(DcsServizi2Sdi.groovy:20){noformat}
> The exception occurs at this line:
> {{IHello hello = cli.parseFromSpec(IHello, argz)}}
> The exception goes away (and all works fine) if I replace it with:
> {{def hello = cli.parseFromSpec(IHello, argz)}}
> I tried to downgrade Groovy down to version 2.5.0 and I always get the
> exception. So this really puzzles me, since the mentioned tutorial is quite
> simple and straight to follow...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8975) GroovyCastException on the result of CliBuilder.parseFromSpec
[
https://issues.apache.org/jira/browse/GROOVY-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated GROOVY-8975:
Attachment: GROOVY-8975.zip
> GroovyCastException on the result of CliBuilder.parseFromSpec
> -
>
> Key: GROOVY-8975
> URL: https://issues.apache.org/jira/browse/GROOVY-8975
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.5
>Reporter: Mauro Molinari
>Assignee: Remko Popma
>Priority: Major
> Attachments: GROOVY-8975.zip
>
>
> I'm trying to follow the tutorial about the use of CliBuilder in Groovy with
> Groovy 2.5.5. Copying the code at [Annotating methods of an
> interface|https://github.com/remkop/picocli/wiki/Groovy-2.5-CliBuilder-Renewal#annotating-methods-of-an-interface]
> paragraph, at runtime I have the following Exception:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20)Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(DcsServizi2Sdi.groovy:20){noformat}
> The exception occurs at this line:
> {{IHello hello = cli.parseFromSpec(IHello, argz)}}
> The exception goes away (and all works fine) if I replace it with:
> {{def hello = cli.parseFromSpec(IHello, argz)}}
> I tried to downgrade Groovy down to version 2.5.0 and I always get the
> exception. So this really puzzles me, since the mentioned tutorial is quite
> simple and straight to follow...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GROOVY-8975) GroovyCastException on the result of CliBuilder.parseFromSpec
[
https://issues.apache.org/jira/browse/GROOVY-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned GROOVY-8975:
---
Assignee: Remko Popma
> GroovyCastException on the result of CliBuilder.parseFromSpec
> -
>
> Key: GROOVY-8975
> URL: https://issues.apache.org/jira/browse/GROOVY-8975
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.5
>Reporter: Mauro Molinari
>Assignee: Remko Popma
>Priority: Major
>
> I'm trying to follow the tutorial about the use of CliBuilder in Groovy with
> Groovy 2.5.5. Copying the code at [Annotating methods of an
> interface|https://github.com/remkop/picocli/wiki/Groovy-2.5-CliBuilder-Renewal#annotating-methods-of-an-interface]
> paragraph, at runtime I have the following Exception:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20)Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(DcsServizi2Sdi.groovy:20){noformat}
> The exception occurs at this line:
> {{IHello hello = cli.parseFromSpec(IHello, argz)}}
> The exception goes away (and all works fine) if I replace it with:
> {{def hello = cli.parseFromSpec(IHello, argz)}}
> I tried to downgrade Groovy down to version 2.5.0 and I always get the
> exception. So this really puzzles me, since the mentioned tutorial is quite
> simple and straight to follow...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8975) GroovyCastException on the result of CliBuilder.parseFromSpec
[
https://issues.apache.org/jira/browse/GROOVY-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770249#comment-16770249
]
Remko Popma commented on GROOVY-8975:
-
[~daniel_sun] Thanks for the heads-up, I wasn't aware of this. Taking a look
now.
> GroovyCastException on the result of CliBuilder.parseFromSpec
> -
>
> Key: GROOVY-8975
> URL: https://issues.apache.org/jira/browse/GROOVY-8975
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.5
>Reporter: Mauro Molinari
>Assignee: Remko Popma
>Priority: Major
>
> I'm trying to follow the tutorial about the use of CliBuilder in Groovy with
> Groovy 2.5.5. Copying the code at [Annotating methods of an
> interface|https://github.com/remkop/picocli/wiki/Groovy-2.5-CliBuilder-Renewal#annotating-methods-of-an-interface]
> paragraph, at runtime I have the following Exception:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(MyMain.groovy:20)Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object
> '{help=groovy.cli.picocli.CliBuilder$_extractAttributesFromMethod_closure12@3bb9a3ff}'
> with class 'java.util.LinkedHashMap' to class 'mypackage.IHello' due to:
> groovy.lang.GroovyRuntimeException: Could not find matching constructor for:
> mypackage.IHello(LinkedHashMap)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:412)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:328)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:242)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:617)
> at mypackage.MyMain.main(DcsServizi2Sdi.groovy:20){noformat}
> The exception occurs at this line:
> {{IHello hello = cli.parseFromSpec(IHello, argz)}}
> The exception goes away (and all works fine) if I replace it with:
> {{def hello = cli.parseFromSpec(IHello, argz)}}
> I tried to downgrade Groovy down to version 2.5.0 and I always get the
> exception. So this really puzzles me, since the mentioned tutorial is quite
> simple and straight to follow...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8968) Upgrade picocli to 3.9.2 from 3.7.0
[ https://issues.apache.org/jira/browse/GROOVY-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751661#comment-16751661 ] Remko Popma commented on GROOVY-8968: - Found it: http://ci.groovy-lang.org/ > Upgrade picocli to 3.9.2 from 3.7.0 > --- > > Key: GROOVY-8968 > URL: https://issues.apache.org/jira/browse/GROOVY-8968 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.5 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.6 > > > Upgrade picocli to 3.9.2 from 3.7.0. > Potential impact: small change in usage help message format in > https://github.com/remkop/picocli/releases/tag/v3.8.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8968) Upgrade picocli to 3.9.2 from 3.7.0
[ https://issues.apache.org/jira/browse/GROOVY-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751084#comment-16751084 ] Remko Popma commented on GROOVY-8968: - What was the URL for the Continuous Integration server again? > Upgrade picocli to 3.9.2 from 3.7.0 > --- > > Key: GROOVY-8968 > URL: https://issues.apache.org/jira/browse/GROOVY-8968 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.5 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.6 > > > Upgrade picocli to 3.9.2 from 3.7.0. > Potential impact: small change in usage help message format in > https://github.com/remkop/picocli/releases/tag/v3.8.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8968) Upgrade picocli to 3.9.2 from 3.7.0
Remko Popma created GROOVY-8968: --- Summary: Upgrade picocli to 3.9.2 from 3.7.0 Key: GROOVY-8968 URL: https://issues.apache.org/jira/browse/GROOVY-8968 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.5 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.6 Upgrade picocli to 3.9.2 from 3.7.0. Potential impact: small change in usage help message format in https://github.com/remkop/picocli/releases/tag/v3.8.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8867) Bump picocli to 3.7.0 from 3.6.0
[ https://issues.apache.org/jira/browse/GROOVY-8867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved GROOVY-8867. - Resolution: Fixed > Bump picocli to 3.7.0 from 3.6.0 > > > Key: GROOVY-8867 > URL: https://issues.apache.org/jira/browse/GROOVY-8867 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.3 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.4 > > > CliBuilder-related: bump picocli to 3.7.0 from 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8867) Bump picocli to 3.7.0 from 3.6.0
[ https://issues.apache.org/jira/browse/GROOVY-8867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-8867. --- > Bump picocli to 3.7.0 from 3.6.0 > > > Key: GROOVY-8867 > URL: https://issues.apache.org/jira/browse/GROOVY-8867 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.3 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.4 > > > CliBuilder-related: bump picocli to 3.7.0 from 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8867) Bump picocli to 3.7.0 from 3.6.0
Remko Popma created GROOVY-8867: --- Summary: Bump picocli to 3.7.0 from 3.6.0 Key: GROOVY-8867 URL: https://issues.apache.org/jira/browse/GROOVY-8867 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.3 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.4 CliBuilder-related: bump picocli to 3.7.0 from 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8786) Bump picocli to 3.6.0 from 3.5.0
[ https://issues.apache.org/jira/browse/GROOVY-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-8786. --- Resolution: Fixed > Bump picocli to 3.6.0 from 3.5.0 > > > Key: GROOVY-8786 > URL: https://issues.apache.org/jira/browse/GROOVY-8786 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.2 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.3 > > > Bump picocli to 3.6.0 from 3.5.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8786) Bump picocli to 3.6.0 from 3.5.0
Remko Popma created GROOVY-8786: --- Summary: Bump picocli to 3.6.0 from 3.5.0 Key: GROOVY-8786 URL: https://issues.apache.org/jira/browse/GROOVY-8786 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.2 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.3 Bump picocli to 3.6.0 from 3.5.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8740) groovy.util.CliBuilder doesn't handle parse errors correctly
[
https://issues.apache.org/jira/browse/GROOVY-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586711#comment-16586711
]
Remko Popma commented on GROOVY-8740:
-
FYI I fixed the picocli CliBuilder so it behaves the same as the commons-cli
CliBuilder.
> groovy.util.CliBuilder doesn't handle parse errors correctly
>
>
> Key: GROOVY-8740
> URL: https://issues.apache.org/jira/browse/GROOVY-8740
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.1
>Reporter: Роман Донченко
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.2
>
>
> In Groovy 2.5, {{groovy.util.CliBuilder}} is a wrapper that delegates to
> {{groovy.cli.commons.CliBuilder}}. However, this wrapper doesn't correctly
> handle the case when the arguments fail to be parsed.
> Here's how it works with the real {{CliBuilder}}:
> {code:java}
> groovy:000> options = new groovy.cli.commons.CliBuilder(stopAtNonOption:
> false).parse(['-x'])
> error: Unrecognized option: -x
> usage: groovy
> ===> null{code}
> And here's what happens with the wrapper:
> {code:java}
> groovy:000> options = new groovy.util.CliBuilder(stopAtNonOption:
> false).parse(['-x'])
> error: Unrecognized option: -x
> usage: groovy
> ===> groovy.util.OptionAccessor@6fc3e1a4
> groovy:000> options.arguments()
> ERROR java.lang.NullPointerException:
> Cannot invoke method arguments() on null object{code}
> I get an object that pretends to be {{null}}, but isn't. So I can't determine
> whether the parsing was successful or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8759) groovy.cli.picocli.CliBuilder should behave like cli.commons.CliBuilder on invalid options
[
https://issues.apache.org/jira/browse/GROOVY-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved GROOVY-8759.
-
Resolution: Fixed
Fixed by setting the picocli both ParserSpec's {{stopAtPositional}} and
{{unmatchedOptionsArePositionalParams}} properties to the value of
{{stopAtNonOption}}:
{code}
void setStopAtNonOption(boolean stopAtNonOption) {
this.stopAtNonOption = stopAtNonOption
parser.stopAtPositional(stopAtNonOption)
parser.unmatchedOptionsArePositionalParams(stopAtNonOption)
}
{code}
> groovy.cli.picocli.CliBuilder should behave like cli.commons.CliBuilder on
> invalid options
> --
>
> Key: GROOVY-8759
> URL: https://issues.apache.org/jira/browse/GROOVY-8759
> Project: Groovy
> Issue Type: Dependency upgrade
> Components: command line processing
>Affects Versions: 2.5.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.5.3
>
>
> When {{stopAtNonOption: false}} flag is set, the two versions of CliBuilder
> behave differently. (See GROOVY-8740)
> The commons cli version of CliBuilder returns {{null}}:
> {code}
> def optCommons = new groovy.cli.commons.CliBuilder(stopAtNonOption:
> false).parse(['-x'])
> if (optCommons) println "Okay" else println "Error"
> {code}
> The picocli version of CliBuilder returns a non-null options object with the
> {{"-x"}} value as a positional parameter:
> {code}
> def optCli = new groovy.cli.picocli.CliBuilder(stopAtNonOption:
> false).parse(['-x'])
> if (optCli) println "Okay" else println "Error"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8759) groovy.cli.picocli.CliBuilder should behave like cli.commons.CliBuilder on invalid options
Remko Popma created GROOVY-8759:
---
Summary: groovy.cli.picocli.CliBuilder should behave like
cli.commons.CliBuilder on invalid options
Key: GROOVY-8759
URL: https://issues.apache.org/jira/browse/GROOVY-8759
Project: Groovy
Issue Type: Dependency upgrade
Components: command line processing
Affects Versions: 2.5.2
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.5.3
When {{stopAtNonOption: false}} flag is set, the two versions of CliBuilder
behave differently. (See GROOVY-8740)
The commons cli version of CliBuilder returns {{null}}:
{code}
def optCommons = new groovy.cli.commons.CliBuilder(stopAtNonOption:
false).parse(['-x'])
if (optCommons) println "Okay" else println "Error"
{code}
The picocli version of CliBuilder returns a non-null options object with the
{{"-x"}} value as a positional parameter:
{code}
def optCli = new groovy.cli.picocli.CliBuilder(stopAtNonOption:
false).parse(['-x'])
if (optCli) println "Okay" else println "Error"
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8738) Bump picocli version to 3.5.0 from 3.3.0
[ https://issues.apache.org/jira/browse/GROOVY-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-8738. --- > Bump picocli version to 3.5.0 from 3.3.0 > > > Key: GROOVY-8738 > URL: https://issues.apache.org/jira/browse/GROOVY-8738 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.1 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.2 > > > Bump picocli version to 3.5.0 from 3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8738) Bump picocli version to 3.5.0 from 3.3.0
[ https://issues.apache.org/jira/browse/GROOVY-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved GROOVY-8738. - Resolution: Fixed > Bump picocli version to 3.5.0 from 3.3.0 > > > Key: GROOVY-8738 > URL: https://issues.apache.org/jira/browse/GROOVY-8738 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.1 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.2 > > > Bump picocli version to 3.5.0 from 3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8738) Bump picocli version to 3.5.0 from 3.3.0
Remko Popma created GROOVY-8738: --- Summary: Bump picocli version to 3.5.0 from 3.3.0 Key: GROOVY-8738 URL: https://issues.apache.org/jira/browse/GROOVY-8738 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.1 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.2 Bump picocli version to 3.5.0 from 3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8700) Bump picocli version to 3.3.0 from 3.2.0
[ https://issues.apache.org/jira/browse/GROOVY-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved GROOVY-8700. - Resolution: Fixed Fixed on master and GROOVY_2_5_X branches. No need to update GROOVY_2_6_X? > Bump picocli version to 3.3.0 from 3.2.0 > > > Key: GROOVY-8700 > URL: https://issues.apache.org/jira/browse/GROOVY-8700 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.1 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.2 > > > https://github.com/remkop/picocli/releases/tag/v3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8700) Bump picocli version to 3.3.0 from 3.2.0
Remko Popma created GROOVY-8700: --- Summary: Bump picocli version to 3.3.0 from 3.2.0 Key: GROOVY-8700 URL: https://issues.apache.org/jira/browse/GROOVY-8700 Project: Groovy Issue Type: Dependency upgrade Components: command line processing Affects Versions: 2.5.1 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.5.2 https://github.com/remkop/picocli/releases/tag/v3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8646) Bump picocli version to 3.1.0 from 3.0.2
[ https://issues.apache.org/jira/browse/GROOVY-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed GROOVY-8646. --- Resolution: Done > Bump picocli version to 3.1.0 from 3.0.2 > > > Key: GROOVY-8646 > URL: https://issues.apache.org/jira/browse/GROOVY-8646 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.0 >Reporter: Remko Popma >Priority: Major > Fix For: 2.5.1 > > > Picocli [3.1.0|https://github.com/remkop/picocli/releases/tag/v3.1.0] fixes a > bug where an AnnotationFormatError "Duplicate annotation for class" occurred > on Groovy scripts annotated with with @PicocliScript when the script contains > classes. This release also adds support for command aliases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
