> 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.
I would prefer (1), too - from the users point of view. Itīs much easier to
use.
But we can check the new implementation against our old distros (Ant 1.1
e.g. :).
If the validation of that 'old' file passes, the most should be ok.
Jan
