ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: API changes introduced while fixing bug 10755
Date Fri, 07 Feb 2003 10:28:35 GMT
On 07 Feb 2003, Stefan Bodewig <bodewig@apache.org> wrote:

> and send a different one on issues I have myself with the changes.

here it is.

> (1) New data-type Resource

I am aware that this could lead to a VFS layer and has a lot of
potential for future expansions, but for now it has been kept as a
bare minimum.

One thing that I might want to see some stricter contract enforced is
the name.  getName() will currently return names using the platform's
file separator as separator for Files and forward slashes for
ZipEntryies.

I'd prefer to make that always use something predictable, and the
platform's separator may be the better choice.

> (2) New interface ResourceFactory

related to the above: what does the factory expect as argument to
getResource method.  I'd like to tighten the contract.

Currently it will accept names using \ or / and do the right thing
(implicitly as java.io.File does for Files and explicitly in
ZipScanner for ZipEntry).  I'd like to make that a requirement along
the lines of "be open in what you get and strict in what you return"
or so.

> (3) New interface ResourceScanner

I'm not convinced that this is really needed (at this point).

If you look at the implenentation in DirectoryScanner, the new methods
are a mere convenience layer on top of getIncludedFiles/Directories.
The same is true for the implementation in ZipScanner, even if it is
less visibly so.

This may be useful at some future point if we wanted to extend other
tasks to work on Resource objects instead of filenames.

> (4) New utility class SourceSelector.
> 
> chosing some better names on the way.

At least I hope so.  8-)

Also the names should help us if we want to use different selection
mechanisms in the future.

> (6) ZipScanner now really parses the archive instead of returning
> the archive itself in getIncludedFiles.

I have an issue with the implementation, not with the API.

ZipScanner now wants a Task instance to log to.  This should probably
be a ProjectComponent so that ZipFileSet can point to itself in
getDirectoryScanner.  Or maybe it should get the Project instance
directly?

Furthermore, errors get just logged, I'd prefer to really bail out and
throw a BuildException here.  The problem is that these are going to happen in
getIncluded*() methods, that are not declared to throw anything (I
know BuildException is not a checked exception, but it doesn't look
right to throw them without telling the user).

Stefan

Mime
View raw message