On 25 May 2011 10:04, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
These were Nicolas' tests, but a good catch and I've made the change.
BTW, the aim here is to reproduce the bugs for the first go... so if
Plexus Utils is incorrectly using platform encoding then actually the
test
On 26 May 2011 12:57, sebb seb...@gmail.com wrote:
On 25 May 2011 10:04, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
These were Nicolas' tests, but a good catch and I've made the change.
BTW, the aim here is to reproduce the bugs for the first go... so if
Plexus Utils is
The only way I can consider of testing this reliably is to keep the test
code using platform encoding and have two executions of surefire, the first
leaving things as is and the second with file.encoding set to a different
value.
For http://jira.codehaus.org/browse/SUREFIRE-740 I had to use
On 26 May 2011 15:03, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
On 26 May 2011 12:57, sebb seb...@gmail.com wrote:
On 25 May 2011 10:04, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
These were Nicolas' tests, but a good catch and I've made the change.
BTW, the
notice that encoding (US-ASCII or UTF-8) should be precised both when
converting String to byte[] and byte[] to String, or you're implicitely using
platform encoding which is not the best: if anybody tries to run tests on an
EBCDIC platform, they will fail (I know, this is quite rare, but
These were Nicolas' tests, but a good catch and I've made the change.
BTW, the aim here is to reproduce the bugs for the first go... so if
Plexus Utils is incorrectly using platform encoding then actually the
test would be correct! So it may be that we revert this... should
probably add an
Fun to know we will have to hack commons-io to backport plexus-utils bugs ;)
2011/5/25 Stephen Connolly stephen.alan.conno...@gmail.com
These were Nicolas' tests, but a good catch and I've made the change.
BTW, the aim here is to reproduce the bugs for the first go... so if
Plexus Utils is
