commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [VOTE] Release Commons CLI 1.2 (RC6)
Date Sat, 14 Mar 2009 09:08:38 GMT
On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible <> wrote:
> Henri Yandell wrote:
>> One more try :)
>> Stating that the Java version is 1.4 on the website will be done
>> post-release (I'm going to split the CLI and CLI2 websites).
> Actually I could not let go this failing test with IBM JDK running on Maven
> without any reason. And finally I found out the problem. Looking at the
> failing test, it was clear that something must have been left in the
> OptionBuilder from a previous test. Therefore I've added some code to
> OptionBuilder.create that printed out the last method on the stack that was
> not from OptionBuilder. I found out that the last test before the failing
> HelpFormatterTest.printOptionGroupUsage that made usage of the
> OptionBuilder was OptionBuilderTest.testCreateIncompleteOption. In this
> method an argument is added and then create fails throwing an IAE and the
> OptionBuilder.reset method is therefore not called. A lot of unit tests
> later the HelpFormatterTest.printOptionGroupUsage is the first test that
> makes usage of the OptionBuilder again ... and "inherits" that old
> argument. The problem appears only because the sequence of the tests are
> different for the IBM JDK 6 in Maven.
> The question is: What should a user expect from the OptionBuilder? If
> OptionBuilder.create() throws IAE (or he forgets to call create), the next
> usage of the builder will "inherit" the old settings. OTOH both situations
> are programming errors. This might be viewed as minor problem though, since
> the OptionBuilder is normally used in an early stage of the application
> flow only. At least something should be in the JavaDoc that this class is
> not thread safe and that create() must be called to reset the builder for
> the next usage.
> Therefore we may either ensure that a call to create will always reset the
> builder in case of an IAE (CLI-177) or we can simply fix the tests that use
> the builder by calling reset manually in the setUp (actually we must create
> a simple option, since reset is private). Shall I commit this?

I think fixing the tests and adding javadoc is best right now. We can
evaluate CLI-177 after that, but I don't want to hold up a release and
this is the kind of fix that would be nice to have sitting in trunk
for a while being picked up by people before baking it in.

Let me know when you've done that and I'll spin another RC out.

Many thanks,


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

View raw message