On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible <joerg.schai...@gmx.de> 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, Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
