IllegalStateException thrown (as it's not a direct argument) when there's not enough width to possibly output things and remain in the width.
I'll give it a short period for any discussion and spin off another release candidate. Hen On Wed, Feb 18, 2009 at 11:37 PM, Henri Yandell <flame...@gmail.com> wrote: > I've been digging in a bit further. A few issues: > > * The 1.0/1.1 feature for a long line is to output it, rather than cut > it up as the change below. So this is a feature change, but I agree > with you on this being how it should work. > > * You can still cause infinite loops if you request something silly, > ie: the width is less than the flag, longflag and prefix. Previously > it used width + arg indent + prefix due to the fixed CLI-151 bug. I > think this should be an IllegalArgumentException. > > Hen > > On Wed, Feb 18, 2009 at 10:54 PM, Gary Gregory > <ggreg...@seagullsoftware.com> wrote: >> Good news all around. >> Thanks Hen, >> Gary >> >> -----Original Message----- >> From: Henri Yandell [mailto:flame...@gmail.com] >> Sent: Wednesday, February 18, 2009 9:08 PM >> To: Commons Developers List >> Subject: Re: [VOTE] CLI 1.2 release (RC2) >> >> So committed. I thought it would be harder to implement it that way >> but turned out to be easier. >> >> On Wed, Feb 18, 2009 at 9:55 AM, Gary Gregory >> <ggreg...@seagullsoftware.com> wrote: >>> Hi Hen: >>> >>> In my mind, the width is like a newspaper column, or a page in a book, it >>> always wraps, no matter what. The issue is how is a word broken up. My vote >>> is to chop and wrap, so that no matter what, you get all of the text in the >>> given width. >>> >>> Gary >>> >>> -----Original Message----- >>> From: Henri Yandell [mailto:flame...@gmail.com] >>> Sent: Tuesday, February 17, 2009 9:45 PM >>> To: Commons Developers List >>> Subject: Re: [VOTE] CLI 1.2 release (RC2) >>> >>> This is fixed. Now we need to decide what should happen when text is >>> too large, do we simply output it or do we break it up. >>> >>> ie) in your test case Gary, the codehaus url is longer than the space >>> you provide to print it. Do you expect it to be cut up or to overrun? >>> >>> Currently I let it overrun as that code was simpler. >>> >>> Hen >>> >>> On Tue, Feb 10, 2009 at 6:55 PM, Henri Yandell <flame...@gmail.com> wrote: >>>> I had a stab last night, but didn't figure out how the code should >>>> look to fix it. >>>> >>>> Lack of pronoun = "Equally buried :) My 2 jobs at work are behaving >>>> like 3 right now. " >>>> >>>> I'll keep looking, but not turning away anyone else from looking >>>> either as it's not immediately obvious. >>>> >>>> Hen >>>> >>>> On Tue, Feb 10, 2009 at 1:48 PM, Gary Gregory >>>> <ggreg...@seagullsoftware.com> wrote: >>>>> Hey Hen: >>>>> >>>>> "So need to figure out how to fix that." >>>>> >>>>> Can you look into this issue? I'm buried at work here. I'm not sure if >>>>> you wanted me to do this due to the missing pronoun ;) >>>>> >>>>> Thanks, >>>>> Gary >>>>> >>>>> -----Original Message----- >>>>> From: Henri Yandell [mailto:flame...@gmail.com] >>>>> Sent: Monday, February 09, 2009 10:58 PM >>>>> To: Commons Developers List >>>>> Subject: Re: [VOTE] CLI 1.2 release (RC2) >>>>> >>>>> If I rollback the change from CLI-162, and comment out the >>>>> testInfiniteLoop; your new test also infinite loops. So CLI-162 is a >>>>> sign that something has broken in that class since 1.1, rather than it >>>>> being an existing issue in 1.1. >>>>> >>>>> Rolling back each commit on HelpFormatter, the issue appears to have >>>>> come in with: >>>>> >>>>> ---- >>>>> r654428 | bayard | 2008-05-07 23:40:58 -0700 (Wed, 07 May 2008) | 1 line >>>>> >>>>> Applying J. Lewis Muir's patch from CLI-151 fixing HelpFormatter so it >>>>> wraps properly on multiple lines >>>>> ---- >>>>> >>>>> Said patch was: >>>>> >>>>> Index: src/java/org/apache/commons/cli/HelpFormatter.java >>>>> =================================================================== >>>>> --- src/java/org/apache/commons/cli/HelpFormatter.java (revision 654427) >>>>> +++ src/java/org/apache/commons/cli/HelpFormatter.java (revision 654428) >>>>> @@ -809,7 +809,7 @@ >>>>> while (true) >>>>> { >>>>> text = padding + text.substring(pos).trim(); >>>>> - pos = findWrapPos(text, width, nextLineTabStop); >>>>> + pos = findWrapPos(text, width, 0); >>>>> >>>>> if (pos == -1) >>>>> { >>>>> >>>>> So need to figure out how to fix that. >>>>> >>>>> Hen >>>>> >>>>> On Mon, Feb 9, 2009 at 10:37 PM, Henri Yandell <flame...@gmail.com> wrote: >>>>>> Thanks for the update. >>>>>> >>>>>> It's invoked when I run mvn package: >>>>>> >>>>>> Running org.apache.commons.cli.bug.BugCLI162Test >>>>>> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.013 >>>>>> sec <<< FAILURE! >>>>>> >>>>>> Hen >>>>>> >>>>>> On Mon, Feb 9, 2009 at 8:46 PM, Gary Gregory >>>>>> <ggreg...@seagullsoftware.com> wrote: >>>>>>> Hen: >>>>>>> >>>>>>> Ok, I've updated the class BugCLI162Test in SVN with a failing test. >>>>>>> Note that BugCLI162Test is not invoked during a Maven build. Is this an >>>>>>> omission? How about an AllTests class for the "bug" package? >>>>>>> >>>>>>> Thanks, >>>>>>> Gary >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gary Gregory [mailto:ggreg...@seagullsoftware.com] >>>>>>> Sent: Monday, February 09, 2009 7:58 PM >>>>>>> To: Commons Developers List >>>>>>> Subject: RE: [VOTE] CLI 1.2 release (RC2) >>>>>>> >>>>>>> I'll extract a unit test from our code and post a new ticket. >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henri Yandell [mailto:flame...@gmail.com] >>>>>>> Sent: Monday, February 09, 2009 7:10 PM >>>>>>> To: Commons Developers List >>>>>>> Subject: Re: [VOTE] CLI 1.2 release (RC2) >>>>>>> >>>>>>> I think it's a showstopper - that was a fix due to infinite looping >>>>>>> causing an OOM. Sounds like you have a test case that isn't covered by >>>>>>> the current tests. >>>>>>> >>>>>>> Hen >>>>>>> >>>>>>> On Mon, Feb 9, 2009 at 1:33 PM, Gary Gregory >>>>>>> <ggreg...@seagullsoftware.com> wrote: >>>>>>>> Hello Hen: >>>>>>>> >>>>>>>> I've encountered a backwards compatibility issue in our application >>>>>>>> unit test suite related to [CLI-162]. >>>>>>>> >>>>>>>> With version 1.1, I can print call >>>>>>>> HelpFormatter#printHelp(String,Options) without any problems without >>>>>>>> our options. When I replace 1.1 with 1.2 I get: >>>>>>>> >>>>>>>> Exception in thread "main" java.lang.RuntimeException: Text too long >>>>>>>> for line - throwing exception to avoid infinite loop [CLI-162]: >>>>>>>> >>>>>>>> Since the only thing that I changed is the CLI version, I assume that >>>>>>>> this means that the HelpFormatter format changed between 1.1 and 1.2. >>>>>>>> Is that so? >>>>>>>> >>>>>>>> I worked around this by calling the HelpFormatter API with a width >>>>>>>> large enough to avoid the RE. Sadly this makes CLI 1.2 not 100% binary >>>>>>>> compatible with 1.1. >>>>>>>> >>>>>>>> Before I go any further and extract my code into a JIRA ticket, is >>>>>>>> this a showstopper? If not, there's plenty of work I need to do before >>>>>>>> I spin my wheels on extracting the code. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gary >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Henri Yandell [mailto:flame...@gmail.com] >>>>>>>> Sent: Sunday, February 08, 2009 1:01 PM >>>>>>>> To: Commons Developers List >>>>>>>> Subject: [VOTE] CLI 1.2 release (RC2) >>>>>>>> >>>>>>>> Apologies for the revote. I've added a note to the release page to >>>>>>>> check the NOTICE file's copyright year. >>>>>>>> >>>>>>>> There should be no difference between the two other than the RC1->RC2 >>>>>>>> in the pom and the updated year in the NOTICE file. >>>>>>>> >>>>>>>> >>>>>>>> Tag: >>>>>>>> >>>>>>>> https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC2 >>>>>>>> >>>>>>>> Site remains unchanged: >>>>>>>> >>>>>>>> http://people.apache.org/~bayard/cli-1.2-rc1 >>>>>>>> >>>>>>>> Binaries: >>>>>>>> >>>>>>>> http://people.apache.org/builds/commons/cli/1.2/RC1/staged/commons-cli/commons-cli/1.2/ >>>>>>>> >>>>>>>> [ ] +1 release it >>>>>>>> [ ] +0 go ahead I don't care >>>>>>>> [ ] -1 no, do not release it because >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
