Hi all Should be fixed, with many thanks to Jeremy!
http://jira.public.thoughtworks.org/browse/CCNET-2048 buildArgs="$(myPort) $(myUser) $(myPassword)" and buildArgs=" $(myPort) $(myUser) $(myPassword) " are now parsed to the same, so I think we cover all scenarios now. Unit tests have been added to prevent this in the future. with kind regards Ruben Willems On Wed, Mar 30, 2011 at 3:27 PM, Jeremy Lew <[email protected]> wrote: > I just emailed Ruben a fix for this. The fix is essentially to turn > whitespace handling off when processing attribute values, which do not > require the same special handling that element values/text nodes do. > > On Mar 29, 5:11 pm, Ruben Willems <[email protected]> wrote: > > Hi > > > > this is indeed a work around, so that's a plus. > > I made a unit test for this, and could simulate it, and that's the good > > news. > > > > the bad news is : I can not fix it :-( > > > > this is really complicated code. > > > > What I did find is the following : there is an option in the > pre-processor : > > IgnoreWhitespace > > > > and it seems to be hard-coded to true. > > When I put this value to false, I get an unused node detected error, but > I > > could not find out where. > > > > the base problem is the following : > > ° $(myPort) $(myUser) $(myPassword) is the value of buildargs > > ° in the first run of the pre-processor this gets processed to : > > the lazy fox > > ° next the pre-processor tries to parse this again, and now the problem > > arises. > > the space gets translated via _ProcessTextNode like this : > > if (_Env._Settings.IgnoreWhitespace && > node.Value.Trim().Length > > == 0) return _emptyNodeSet; > > ° the caller of this method does an addRange, and now it seems that > adding > > an emptyNodeSet (which is just an empty array) > > is in fact the space killer > > > > so the fix should be to set the IgnoreWhitespace to false, and fix the > bug > > in the preprocesser. > > maybe the problem is in fact an overflow detection somewhere, but with a > bad > > error message ? > > > > looking further into this, but any help appreciated :-) > > > > test is committed to the trunk. > > > > with kind regards > > Ruben WillemsOn Mon, Mar 28, 2011 at 10:12 AM, parrimore < > [email protected]> wrote: > > > Hi, > > > > > We're seeing a related issue, though it's basically the opposite > problem in > > > that whitespace is being stripped under 1.6 when it wasn't in 1.5. We > have > > > various bits of config files that look something like this: > > > > > <exec executable="foo.bat" > > > baseDirectory="$(myBaseDir)" > > > buildArgs="$(myPort) $(myUser) $(myPassword) > $(myWorkspace)" > > > description="Foo" /> > > > > > Unfortunately under 1.6 it has started stripping out the spaces in the > > > generated buildArgs, ie. as if we'd written > > > > "$(perforceArtServerPort)$(perforceArtUser)$(perforceArtPassword)$(perforceArtWorkspace)" > > > instead. The only way I could get it to work was to rewrite it like > this: > > > > > <exec> > > > <executable>foo.bat</executable> > > > <baseDirectory>$(myBaseDir)</baseDirectory> > > > <buildArgs>$(myPort) $(myUser) $(myPassword) > > > $(myWorkspace)</buildArgs> > > > <description>Foo</description> > > > </exec> > > > > > I'm not really sure why that should make any difference though! > > > > > As 1.6 sadly didn't provide the change I'd hoped for after reading the > > > build notes anyway, we've simply rolled back to 1.5 for now. > > > > > On Tuesday, February 15, 2011 6:55:25 PM UTC, Craig Sutherland wrote: > > > > > Just a quick update on this - it is due to changes in the > pre-processor. In > > >> 1.5 it was (incorrectly) stripping out whitespace, which made it > > >> impossible > > >> to put newlines, double spaces, etc. in an argument. In 1.6 this > problem > > >> was > > >> fixed but now it breaks older configurations :-( > > > > >> We are looking into what we can do about this and hopefully will come > up > > >> with a solution soon, > > > > >> Craig >
