4 messages in org.codehaus.groovy.userRe: [groovy-user] How much of CliBuil...| From | Sent On | Attachments |
|---|---|---|
| Bogdan Calmac | 17 Mar 2008 17:55 | |
| Gerrit Geens | 18 Mar 2008 00:05 | |
| Russel Winder | 18 Mar 2008 00:33 | |
| Russel Winder | 18 Mar 2008 00:40 |
| Subject: | Re: [groovy-user] How much of CliBuilder does work? |
|---|---|
| From: | Russel Winder (russ...@concertant.com) |
| Date: | 03/18/2008 12:33:27 AM |
| List: | org.codehaus.groovy.user |
On Mon, 2008-03-17 at 17:55 -0700, Bogdan Calmac wrote:
I try to create a sample HelloWorld script according to the Mailman example from "Groovy in Action" and some basic things don't seem to work. I apologize in advance if it's only my ignorance.
Welcome to the extremely weirdly broken world of Commons CLI 1.0 -- unfortunately CLI 1.1 is broken in even more weird ways which is why we backed out of the upgrade from 1.0 to 1.1 some time ago. CLI 2.0 exists, as indeed does 2.1, but has never actually been formally released. It strikes me as unsafe to try working with an unreleased product that no-one is actively working on -- and has not been for many, many months.
1. an option is not recognized when using the long arg form
You cannot access options using long form in CLI 1.0, you always have to use the short form. Consequently, you cannot have long-form only options.
Here I create a CLI with a single required argument and try to use the long arg form:
def cli = new CliBuilder(usage: 'groovy Hello -t') cli.t(argName:'person', longOpt:'to', args:1, required:true, 'person to say hello to') opt = cli.parse(['--to', 'me']) println "t: $opt.t"
It prints out:
t: --
instead of
t: me
By default, CliBuilder uses the PosixParser which behaves exactly as you see. This is a Commons CLI "feature" and not a problem of CliBuilder or anything in Groovy. The GnuParser does not suffer this particular feature, so if you use:
def cli = new CliBuilder(usage: 'groovy Hello [options]', new org.apache.commons.cli.GnuParser ( ) )
it should go away.
2. the option cannot be accessed with argName as described in the book: "If an argName such as myArgName was specified for the x option, then options.x and options.myArgName return the same value"
Well that is what the manuals say but if you actually run programs then this is not the case. Perhaps this is a situation where Dierk et al. did not run an experiment. Or if they did then it would be really good to know what the experiment was and how it worked.
Here I use the same CLI and try to access the value with opt.person:
def cli = new CliBuilder(usage: 'groovy Hello -t') cli.t(argName:'person', longOpt:'to', args:1, required:true, 'person to say hello to') opt = cli.parse(['-t', 'me']) println "person: $opt.person"
It prints out:
person: false
which means it doesn't know about the 'person' argName.
The same thing happens if the arguments are passed in the cmdline. I've put everything in the script to make it easier for you to run. I am using groovy 1.5.4.
With Commons CLI 1.0 this just is not going to work. Therefore with Groovy CliBuilder this is just not going to work. If there was one or two people able to work with me, I would propose seeing if we can get energy back into Commons CLI development creating a stream of patches for Henri or someone to commit, and create pressure for a real 2.0 release.
In case these are known limitations of the upstream library, is there any other obvious problem I should guard against?
Using GnuParser instead of PosixParser helps a lot.
Someday Commons CLI 2.0 may be released into Maven, at which point it becomes sensible to try it out instead of 1.0. cf. https://issues.apache.org/jira/browse/CLI-143
-- Russel. ==================================================== Dr Russel Winder Partner
Concertant LLP t: +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077