Hello Stefan, I have found out that the root cause of the test failures found is the java vm running with file.encoding set to ASCII.
The tests that fail are written in such a way that they assume that Ant is running with file.encoding=UTF-8 which is the default it seems in a lot of Java 1.6 VMs (but not all). Also, by default StringResource instances have a "null" encoding, which works when the encoding of the VM is UTF-8. I am making a change to change the default encoding of StringResource to "UTF-8" which seems to lead to better results when the VM is running under ASCII encoding ( ANSI_X3.4-1968 precisely). Also, I found out that the <contains/> selector needs an encoding attribute to have a chance to do its job when the encoding of the files to select is different from the default encoding of the JVM. I am addressing that by adding an encoding attribute on the contains selector. Regards, Antoine On Mar 3, 2013, at 5:19 AM, Stefan Bodewig wrote: > On 2013-02-19, Antoine Levy Lambert wrote: > >> I am currently looking at the test failures of Ant under linux with >> Oracle JDK 1.6 here [1]. > >> These tests are referenced from the Nightly+ Continuous Builds page >> [2] under Apache Ant - Core Trunk (Linux) > > I'd rather work with <https://builds.apache.org/job/Ant-Build-Matrix/> > which isn't really green (or blue) either. We may want to fix the > nightly builds page. > >> I would like to fix this so that we have a set of green lights before >> doing the release. > > +1 unless what you see is really due to environmental issues on the > server. You shouldn't waste your time debugging a remote system you > don't have access to, IMHO. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org