commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: [CLI] Version 2.0 - API
Date Tue, 04 Mar 2003 01:31:03 GMT
OptionGroup.containsOption(Option) seems redundant.  Maybe 
OptionGroup.contains(Option) would be better?  It also would match the Java 
standard collections api.

OptionGroup.isMandatory():  I would use the term "required" instead of 
mandatory but it's not a big deal.

OptionBuilder.isMandatory() returns an OptionBuilder.  Normally "is" methods 
return a boolean.  The factory methods in this class (and ArgumentBuilder) 
should probably all start with "create" for clarity (ie. createWithChild()).

>From my brief overview of the javadoc I think I like this better than 1.0 


>From: John Keyes <>
>Reply-To: "Jakarta Commons Developers List" 
>To: commons-dev <>
>Subject: [CLI] Version 2.0 - API
>Date: Tue, 4 Mar 2003 00:06:19 +0000
>Hi guys,
>I've put some work into implementing the second version of CLI.  There is
>some work to do to help ease the pain of people migrating from version 1.
>So if people have been using version 1, please please please go look at the
>Javadoc and let me know if you see problems.
>There were a few reasons why I undertook the task of reimplementing the
>API.  One of the reasons was to build in support for Java properties (i.e.
>-Dproperty=value).  Also, the fact that there were three different parser
>implementations served to confuse the use of CLI.  So, I have reimplemented
>it so there is only one implementation.  This will make the use case much
>simpler.  There was also very little differentiation between boolean 
>options and
>options that had values.  So I have introduced the Argument type for 
>that have values, boolean options are represented by the Option type.
>In version 1, when building the an Option there were two ways to do it,
>via a builder or via helper methods on the Options instance.  I have 
>the helper methods and now it means the only way to create instances is
>via the Builders.
>There are currently only two builders, OptionBuilder and ArgumentBuilder.
>I will be adding the PatternOptionBuilder and I will introduce the 
>builder (Nick Chalkos submission) also.  There will also be an XSLT 
>that will transform an XML representation of an options definition into a
>class that constructs the Options.  The reflection builder and this 
>should buffer users from any further API change on the definition side, if
>the API changes again in future releases.  I would hope that it doesn't 
>after this, it has dragged on too long already....
>Some other points of note are, support for child options, support for 
>options e.g. in ant [target1 [target2 ...]], in maven [goal1 [goal2 ...]].
>I think thats everything, so have a read of the Javadoc and send in your 
>When we have had this discussion I will send a mail to commons-user to see 
>there are any other comments that could be useful.
>-John K
>- - - - - - - - - - - - - - - - - - - - - - -
>Jakarta Commons CLI
>To unsubscribe, e-mail:
>For additional commands, e-mail:

The new MSN 8: smart spam protection and 2 months FREE*

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

View raw message