commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russel Winder <>
Subject Re: [cli] Are there any 1.0 -> 1.1/1.2-SNAPSHOT upgrade notes
Date Tue, 03 Jun 2008 16:23:05 GMT

On Mon, 2008-06-02 at 19:03 +0200, Emmanuel Bourg wrote:

> Thank you for testing CLI 1.2, your feedback is much welcome.

No problem.  I have branches of the 1.x branch and trunk and am
installing into my local Maven repository from there.  Testing new
checkins to the Subversion store is therefore easy.

> One important difference of CLI 1.1 is that options are only 
> instantiated once. With your example, the two -J options are 
> materialized by a single Option with 4 values, but since you specified 
> hasArgs(2), the Option actually holds 2 values (source, 1.5).

Having sent the message and started reading my old test code I
remembered this.  I suspect that the whole of this multiple arguments
1.0/1.1 thing is probably the heart of all my problems :-(

> So the solution to "fix" your example with CLI 1.1 is to change 
> hasArgs(2) into hasArgs(), and then get the list of values for the -J 
> option with cmdline.getOptionValues('J'). This will return an array with 
> [source, 1.5, target, 1.5].

Actually I think that will give [ 'source=1.5' , 'target=1.5'] but that
is fine.

However, there is then the problem that all subsequent parameters get
absorbed into the -J list.  I just added a unit test example on

> I don't think this is the right behavior, the number of arguments should 
> be per occurrence of the option, and we should add a property telling if 
> the option is repeatable.

This is the 1.0 semantics I think.  I guess the question is why did the
semantics get changed, there must have been a rationale.

Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

View raw message