Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <879A5AD5DD0ED511891F0003473A9B560E23F608@Z011004>
From: Jan.Materne@rzf.fin-nrw.de
To: dev@ant.apache.org
Subject: AW: Changed default output of <checksum>
Date: Fri, 17 Sep 2004 09:41:29 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C49C89.BEAA2210"

------_=_NextPart_001_01C49C89.BEAA2210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> when I implemented the "make output of <checksum> configurable" part,
> I had to change the default output of the task.
>=20
> 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).
>=20
> 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.
>=20
> The alternatives I considered:
>=20
> (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.
>=20
> (2) Include newline in pattern, but not the one used for default
> format, automagically remove it when parsing an existing checksum
> file.
>=20
> 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.
>=20
> (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.
>=20
> 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.
>=20
> 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=B4s 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

------_=_NextPart_001_01C49C89.BEAA2210--