Hi,
when I implemented the "make output of <checksum> configurable" part,
I had to change the default output of the task.
Originally the output would contain the checksum only, now it will
contain an additional newline (platform specific) after the checksum.
This won't make any difference to the task when validatin checksums
since it reads the original file with readline (and thus discards the
newline).
With my changes you can now specify the output format with a
MessageFormat style pattern. The pattern for GNU's md5sum or BSD's
md5 would need to end in a newline character since the files those
tools generate contain them. When reading back a file formatted like
this, the task would have to strip the newline from the pattern or
MessageFormat would fail to parse the input, something that looked
messy.
The alternatives I considered:
(1) Don't include a newline in the patterns at all, automagically add
one when writing the checksum to a file. Breaks default format but
probably nothing that uses it.
(2) Include newline in pattern, but not the one used for default
format, automagically remove it when parsing an existing checksum
file.
This would also mean that users had to remember to add the newline if
they wanted to specify a custom format - and the'd have to use
${line.separator} to be cross-platform.
(3) Include newline in pattern, but not the one used for default
format. Don't use readline when reading an existing checksum, but
match on the newline characters.
Again people would have to remember to include ${line.separator} in
their custom patterns. Additionally the task would no longer consider
a checksum file valid that has been created on a different platform
and it wouldn't consider checksum files valid that used the default
format but contained an additional line feed for an unknown reason -
such files would validate successfully under any older version.
I opted for (1) but maybe anybody can see yet another option that
allowed us to keep full backwards compatibility. (2) would do, but I
favoured (1) because of the usablity aspect for custom formats.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
