commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [cli] commons cli version 2.0?
Date Fri, 01 Oct 2004 17:52:26 GMT


Andrew Ferguson wrote:
> 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?
> 

Hmmm, something specific to Command might be doable but I'd like to keep 
things general if at all possible.  I'm certainly concerned that the commands 
might or might not be at the top level, but I also think there may be a more 
general case for customising the context for the HelpFormatter to show when an 
exception has occurred.

I'm pondering allowing options further up the chain to catch any 
OptionExceptions and wrap them in some new HelpNeededException which would 
identify the level of context to display.  I'd need to think it through a bit 
longer but I think it might be workable.

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

Hmmm, this sounds like a bug.  I'll investigate the testcase and report back.

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

Will have a think about how such skewing would work and what the implications 
might be!

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

Interesting that both of us seem to have misremembered what cvs and svn do! - 
until I checked earlier I could have sworn that cvs and svn were much more 
helpful than they are!

Cheers,

Rob

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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message