commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <>
Subject Re: [CLI] some thoughts
Date Tue, 13 Aug 2002 23:44:16 GMT

There is another casualty of following the approach I have
taken.  As the call to Options.getOption( ) now returns a
clone of the Option rather than the Option itself the
following style is not possible:

Option j = OptionBuilder.create();
options.addOption( j );
CommandLine line = parser.parse( new String[] { "-j", "jvalue" } );
// this will print null
System.out.println( j.getValue() );

I don't think this is too common an approach that will be taken
anyway, but it is slightly annoying.

I am still +1 on going ahead with the current approach.  If anyone
has a problem please holler before this time tomorrow coz I am
hoping to get this stuff tidied up and commited then.

-John K

On Monday, August 12, 2002, at 09:46 , John Keyes wrote:

> I have been mucking about with some changes that would reflect
> some of the ideas Berin has mentioned over the last couple of
> weeks.
> I do like this new model of processing Options but I would like
> to also maintain the previous model as I like the idea of the
> flexibility.
> So from my experiments I can support the current API and also
> support the new style suggested i.e. the Avalon approach.
> The only casualty of this change is the withArgs( int ) method,
> which allows the user to specify the number of arguments that
> an Option can have.  This feature was only added last week and
> I added it because I misunderstood the request from Berin for
> support of the property style Option values.
> The withCharSeparator method on OptionBuilder can support this.
> Instead of using withArgs( int ) the withCharSeparator can be
> used to exclusively process these properties.  The default char
> separator is '='.  This can be changed for path properties ':'
> or ';'.
> The new implementation would also mean the code that splits the
> option values now resides in the Option as opposed to the individual
> parsers.
> When this is complete I think we are set for a beta release.
> -John K
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> For additional commands, e-mail: <mailto:commons-dev-

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message