ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <>
Subject Re: API changes introduced while fixing bug 10755
Date Thu, 13 Feb 2003 22:13:28 GMT
Thanks for your comments Bruce.

Antoine Lévy-Lambert
----- Original Message -----
From: "Bruce Atherton" <>
To: "Ant Developers List" <>
Sent: Thursday, February 13, 2003 10:52 PM
Subject: Re: API changes introduced while fixing bug 10755

> At 02:28 AM 2/12/2003, Antoine Levy-Lambert wrote:
> >4) for the future
> >
> >I think we should change a number of method signatures to use Resource
> >instead of File.
> s/change/add/ (and mark the old methods deprecated), at least for methods
> already in a release. Until we decide it is time to clean out the cruft
> release Ant 2.
> >I have the following in mind :
> >     - adding new properties to the Resource class
> The eventual plan would be to make this Resource class represent an entry
> in a virtual file system. Therefore, it should provide either a subset of
> all common properties on the different file systems (not desirable as it
> far too limiting) or a superset of properties with sensible behaviour when
> a property is used on a file system that doesn't provide it. Whether that
> behaviour is a BuildException, a warning message, or some default
> would depend on the specific circumstances. So, for example, attempting to
> get the compressed size of a file on disk could just return the regular
> size of the file.
> >     - create a new routine in DirectoryScanner called Resource []
> >ListDir(Resource base)
> Personally, I'd like to see a completely different use of Scanners in the
> system. Conceptually, I don't think Tasks should work with Scanners
> directly, but instead get everything they need from fileset
> of AbstractFileSet (AbstractResourceSet?). Scanners should be command
> objects that populate the required fields of the fileset. Whether the
> contents of the fileset come from a scanner or the hand of god is not
> something a task should be concerned about.
> Eventually. And for the foreseeable future, the old way has to continue to
> work as well.
> >it might ... pave the way for
> >doing new things, like using a ZipFileSet as a source in the <copy> task
> Or an FTPFileSet, or a DAVFileSet, or a CVSRevisionSet, or ...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message