ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject attribute and element namings of the archiving tasks.
Date Fri, 21 Dec 2001 04:03:25 GMT
I'm going to put my hand up as the naming police for ant1.9, and I want to
make an early start with ant1.5, looking at the
{zip,tar,jar,gzip,bzip} tasks, giving them a consistent use of srcFile,
srcDir, destFile and destDir. This is for consistency, learning and easier
cut and
paste work.

1. Peter made zip, war and jar consistent by adding the file attribute after
the 1.4.1 release to spec the output file. However, this attribute is often
used for source files as well as dest files.

I would like to replace this with the 'destFile' attribute; leaving the old
warfile, jarfile stuff in there as deprecated, adding deprecation to the
file attr, and pulling the file attribute from the docs. Only people using
CVS version of ant1.5 will have encountered this attribute.

2. gzip, bzip2 need srcFile and destFile attributes, and should add
dependency testing to not create the dest if it is up to date. Right
now their docs talk about tofile as the name of the output file, but the
current source
uses zipfile as the source file which is another little consistency issue. I
a patch for the docs there.

3. Unjar/Untar/Unwar/Unzip can take the srcFile and destDir attrs as aliases
for their existing stuff

4. Gunzip. Bunzip2 can take srcFile easily. Its dest attribute can be either
a file or a directory, with different behavior in each case. I'd like to add
explicit destDir and destFile attributes and behaviour, which would be
trickier and need more tests.

5. <tar> only takes <tarfileset> as a parameter, even if you don't want to
spec username, mode, etc. I'd like to add <fileset> support; the way I
envisage this is to have an addFileSet(FileSet fileset) method which creates
a new tarfileset for every fileset

public void addFileSet(FileSet fileset) {
    filesets.addElement(new TarFileSet(fileset));

None of this would break anything, we just add more 'deprecated' cruft
(sigh), but gain a simpler conceptual model for end users.



ps, there is that talk by scott mcnealy where he goes that the only thing
he'd like to have a monopoly on after windows is English, so he could
introduce new letters like "f" and charge for an upgrade. But what would
Sun's deprecation policy be? Would 'w' ever be deprecated, leaving welsh
towns like 'bwlch' utterly unpronounceable?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message