Hello Martijn,
if you have the time to do it the file comparison function that ignores
line endings sounds good.
Cheers,
Antoine
Martijn Kruithof wrote:
Hi
I actually used the same technique as proposed in the bug report on
the recorder test cases. Stefan modified that one in such a way that
Kev Jackson wrote:
If this is related to MD5 checksums, they've recently been proven to
not be conclusive proof that the content of the file is the same as
the checksum, ie two different files can create the same checksum
under certain conditions.
Maybe it would be a good idea to add a warning to
On Wed, 8 Dec 2004, Matt Benson [EMAIL PROTECTED] wrote:
Hmm... maybe we should just change the unit test to read the files
(using loadfile with a striplinebreaks filter) into properties
and compare those rather than using FileUtils.contentEquals(...)?
+1
Stefan
On Wed, 8 Dec 2004, Dominique Devienne [EMAIL PROTECTED] wrote:
Isn't the alternative simply to check in the expected files are
binary to avoid line ending conversions at all?
Won't work since the result of running checksum produces platfirm
dependent line ends.
Stefan
On Wed, 08 Dec 2004, Martijn Kruithof [EMAIL PROTECTED] wrote:
I actually used the same technique as proposed in the bug report on
the recorder test cases. Stefan modified that one in such a way that
not the files from cvs are fixed but copies of those files.
I mainly did so since otherwise
If this is related to MD5 checksums, they've recently been proven to not
be conclusive proof that the content of the file is the same as the
checksum, ie two different files can create the same checksum under
certain conditions.
Not sure if this is relevant to the discussion
Stefan Bodewig wrote:
On Wed, 8 Dec 2004, Matt Benson [EMAIL PROTECTED] wrote:
Hmm... maybe we should just change the unit test to read the files
(using loadfile with a striplinebreaks filter) into properties
and compare those rather than using FileUtils.contentEquals(...)?
We could
Kev Jackson wrote:
If this is related to MD5 checksums, they've recently been proven to
not be conclusive proof that the content of the file is the same as
the checksum, ie two different files can create the same checksum
under certain conditions.
Yes it is.
Martijn
On 7 Dec 2004, [EMAIL PROTECTED] wrote:
Hack to make the testcases pass.
Sorry, I didn't manage to follow the bug report.
Before I added pluggable output patterns to checksum the tests
passed without the fixcrlf, so they should still do - unless I've
broken something, which seems to be the
I think it is more a cvs client issue.
Some cvs clients on windows convert to dos endings (correct behaviour
for non-binary files)
and some do not (cygwin cvs client I think does not).
Peter
Stefan Bodewig wrote:
On 7 Dec 2004, [EMAIL PROTECTED] wrote:
Hack to make the testcases pass.
On Wed, 08 Dec 2004, Peter Reilly [EMAIL PROTECTED] wrote:
I think it is more a cvs client issue. Some cvs clients on windows
convert to dos endings (correct behaviour for non-binary files) and
some do not (cygwin cvs client I think does not).
Still, if it worked before ...
Stefan
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On Wed, 08 Dec 2004, Peter Reilly
[EMAIL PROTECTED] wrote:
I think it is more a cvs client issue. Some cvs
clients on windows
convert to dos endings (correct behaviour for
non-binary files) and
some do not (cygwin cvs client I think does
Actually, I have had a quick look at the changes you made.
I do not believe that they will work on windows with
a dos style cvs client.
For example:
the xml target is now:
target name=createMd5
checksum file=../asf-logo.gif fileext=.MD5 /
fixcrlf eol=lf srcdir=.. includes=asf-logo.gif.MD5 /
Hey, good point, I follow you... if the cvs client
auto-converts the expected files, then they won't
match the fixcrlf'd files. Hmm... maybe we should
just change the unit test to read the files (using
loadfile with a striplinebreaks filter) into
properties and compare those rather than using
That sounds like a good idea.
Peter
Matt Benson wrote:
Hey, good point, I follow you... if the cvs client
auto-converts the expected files, then they won't
match the fixcrlf'd files. Hmm... maybe we should
just change the unit test to read the files (using
loadfile with a striplinebreaks filter)
--- Matt Benson [EMAIL PROTECTED] wrote:
[SNIP]
match the fixcrlf'd files. Hmm... maybe we should
just change the unit test to read the files (using
loadfile with a striplinebreaks filter) into
properties and compare those rather than using
FileUtils.contentEquals(...)? Any other ideas?
: ant/src/etc/testcases/taskdefs checksum.xml
Hey, good point, I follow you... if the cvs client
auto-converts the expected files, then they won't
match the fixcrlf'd files. Hmm... maybe we should
just change the unit test to read the files (using
loadfile with a striplinebreaks filter
--- Dominique Devienne [EMAIL PROTECTED] wrote:
Isn't the alternative simply to check in the
expected files are binary to avoid line ending
conversions at all? Just thinking out loud. --DD
Maybe, but that at least puts us back to the fixcrlf
fix since the output files are being written with
Hi
I actually used the same technique as proposed in the bug report on the
recorder test cases. Stefan modified that one in such a way that not the
files from cvs are fixed but copies of those files. I would propose to
either go the same way here or take a better approach in actually write
a
bodewig 2004/09/08 07:30:45
Modified:src/etc/testcases/taskdefs checksum.xml
Log:
more to clean up
Revision ChangesPath
1.8 +3 -1 ant/src/etc/testcases/taskdefs/checksum.xml
Index: checksum.xml
antoine 2003/12/18 00:39:06
Modified:.WHATSNEW
src/main/org/apache/tools/ant/taskdefs Checksum.java
src/testcases/org/apache/tools/ant/taskdefs
ChecksumTest.java
src/etc/testcases/taskdefs checksum.xml
Log:
antoine 2003/12/18 00:54:15
Modified:.Tag: ANT_16_BRANCH WHATSNEW
src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
Checksum.java
src/testcases/org/apache/tools/ant/taskdefs Tag:
ANT_16_BRANCH
bodewig 2003/04/09 07:23:01
Modified:src/etc/testcases/taskdefs checksum.xml
Log:
There is no bug
Revision ChangesPath
1.3 +2 -1 ant/src/etc/testcases/taskdefs/checksum.xml
Index: checksum.xml
23 matches
Mail list logo
