commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Ferguson" <Andrew.Fergu...@arm.com>
Subject RE: [cli] commons cli version 2.0?
Date Fri, 01 Oct 2004 14:59:19 GMT
hi,

> My early versions of the CLI2 model included several exceptions
covering the various situations but we merged them all into one feeling
that people
> were unlikely to be interested in the differences.  I assume you want
to know, for a given exception, whether to give tool level help or
command level help?

 yes

> I'm not sure how best to achieve this off hand and am not even sure
that more specific exception classes would help.

 ok, I'll try to think about this more - my initial thought was
something like a MissingCommandException would allow me to catch this
and help solve my particular issue, but in general you might want to
know where in the command-line tree the command was (as its not
necessarily at the top level?) and that might be over-doing things?

> When you say "make no difference" do you mean in the displayed help or
in the processing?
> I'm pretty sure it should validate as you expect: first validating
each of the options and then validating the number of them against the
minimum/maximum.
> I'll try and have a look over the weekend but if you could send me an
example (test case would be ideal) that demonstrates the problem the
it'll be easier to resolve.

oops, sorry - what I meant was that I can have a Group containing two
options, one of which is required and one of which isn't. When it comes
to processing that Group the only constraints that seem to be honoured
are the setMinimum and setMaximum. So for example if you had a Group
with required options r1,r2,r3 and not required options n1,n2,n3 then
you can't use the number of present options alone as the validation
predicate as eg. requiring a minimum of three options would allow
n1,n2,n3

I've attached a test-case RequiredWithinGroupTest.java that hopefully
demonstrates this (it works on my machine:) but if your answer is that
this is the intended behaviour then I guess its not an error - but is
there an alternate way to achieve the following?

	umbrella-tool --umbrella-tool-option1 command --required1
--required2 --required3 --nonrequired1 --nonrequired3 --nonrequired3

> I'm not really sure what to do about this, I think its safe to say
that the defaults can never suit every use.
> I assume you've  discovered and played with DisplaySettings to
customise fullUsageSettings in HelpFormatter?
> I did wonder about automatically switching options to shorter forms
until they all fit on a single line, which might result
> closer to what you're after.  That would have to wait for a later
release though, I think.

ok, I had been thinking that if the Command class was primarily intended
for cvs/svn style applications then the default behaviour should maybe
be skewed towards this by specially recognizing a top-level group of
Commands? but the current HelpFormatter is more than adequate for
achieving the same thing in the client code

also, as you point out svn does not do this (and having just checked
cvs* doesn't either..)

thanks,
Andrew 
* it just has a --help-commands option to display the command list



Mime
View raw message