DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28774>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28774

[PATCH] Use of Jakarta Commons CLI library for command line processing





------- Additional Comments From [EMAIL PROTECTED]  2004-05-05 03:16 -------
Thanks for taking the time to create this patch.

When I first read the patch, my first thought was "no!--not another library!" 
But I do have to say the new code looks much cleaner and more readable.  (Part
of the reason for the previous messy code, I think, was Victor needing to break
out the param parsing into several "parseXXXXOption()" methods, in order to keep
the main parse() function less than 150 or so lines of code.   We at the time
were using a code style tool that recommended not having methods > 150 lines, or
maybe it was 300 or something.) 

Issues I currently see with Commons-CLI:
1) A release version is still unavailable--this may indicate it is not well
supported, or hasn't been supported recently. 

2) Not raising errors on duplicate parameters would appear to be a feature that
a robust CLI library should be able to provide.  The absence of this option
might reduce the usage of this library by other apps, and by the way OS works,
the amount of support this library gets.

3) The fact that both Joerg and Peter have also researched and like Commons-CLI
is a good sign.  Bad sign:  Xalan still just hardcodes their CLI [1]--being
linked into the JDK, they don't like the risk of additional libraries apparently.

[1]
http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/xslt/Process.java?rev=1.62&view=auto

My instinct, however boring, is to "build on stone" again here--once it is
working, it is "nailed down", and you never have to look at it or worry about it
again.  But this is not that important to me (we can easily revert the code if
it later presents a problem--it's only being used in one class), and it
certainly does make the code look cleaner and more maintainable.  I guess either
way is OK for me.

Thanks,
Glen

Reply via email to