ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: API changes introduced while fixing bug 10755
Date Sat, 08 Feb 2003 02:28:22 GMT
At 02:28 AM 2/7/2003, Stefan Bodewig wrote:

>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
>I'd prefer to make that always use something predictable, and the
>platform's separator may be the better choice.

Depending on what you mean by "platform", I think this would would not be 
the best choice since it makes the VFS layer you talked about more 
complicated to eventually do. Would you want URLs, for example, to have 
forward slashes converted to a platform's separators?

If consistency is needed, my preference would be to define a canonical 
"Resource" path separator that works on the majority of potential 
filesystems (aka '/'). This may add a bit more complication up-front, but 
it has the virtue that it will still work in the future we envisage for 
ourselves. The downside is that on some platforms it will involve a lot 
more conversion back and forth.

> > (3) New interface ResourceScanner
>I'm not convinced that this is really needed (at this point).

I have to agree. I'm not sure I see much benefit to an interface like this 
until we go for a fully abstracted file system.

> > (4) New utility class SourceSelector.
> >
> > chosing some better names on the way.
>At least I hope so.  8-)

If the comment at the top of the file is a true indication of what it is 
for, then how about "ResourceProcessingUtils", or perhaps more simply 

>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

Is it necessary that Scanners call the logging API? Couldn't the layer 
around them do that, relying on the information provided through toString() 
and BuildExceptions?

>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).

As someone who hates checked exceptions, I'm probably the wrong person to 
talk to this point. I'll just point out that BuildExceptions already 
percolate throughout the code without necessarily being declared.

View raw message