commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
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 
:-).

David



>From: John Keyes <jbjk@mac.com>
>Reply-To: "Jakarta Commons Developers List" 
><commons-dev@jakarta.apache.org>
>To: commons-dev <commons-dev@jakarta.apache.org>
>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 
>options
>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 
>removed
>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 
>reflection
>builder (Nick Chalkos submission) also.  There will also be an XSLT 
>stylesheet
>that will transform an XML representation of an options definition into a
>class that constructs the Options.  The reflection builder and this 
>stylesheet
>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 
>change
>after this, it has dragged on too long already....
>
>Some other points of note are, support for child options, support for 
>anonymous
>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 
>comments.
>When we have had this discussion I will send a mail to commons-user to see 
>if
>there are any other comments that could be useful.
>
>Cheers,
>-John K
>
>[1] http://www.integralsource.com/cli/2.0alpha1/
>
>- - - - - - - - - - - - - - - - - - - - - - -
>http://www.integralsource.com/weblog
>
>Jakarta Commons CLI
>http://jakarta.apache.org/commons/cli
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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


Mime
View raw message