ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy Lambert <>
Subject Re: Ant 1.9.0
Date Sun, 03 Mar 2013 20:13:28 GMT
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.



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 <>
> 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:
> For additional commands, e-mail:

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

View raw message