ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject AW: Changed default output of <checksum>
Date Fri, 17 Sep 2004 07:41:29 GMT
> 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
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message