ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: Ant2 VFS Proposal
Date Sun, 20 Jan 2002 06:53:45 GMT

> -----Original Message-----
> From: Peter Donald []
> Sent: Sunday, 20 January 2002 1:41 AM
> To: Ant Developers List
> Subject: Re: Ant2 VFS Proposal
> Hi,
> Looks good so far. A few questions

Thanks for looking at this.

> In FileName why have getChild() when there is resolveFile() that 
> does that 
> and much more? Same goes in FileObject?

It's to limit scope - getChild() will only ever return a direct child.  It throws an exception
if the name refers to something else.  Prevents the caller accidentally ending up with a file
in an unexpected location.

It might be worthwhile generalising this into a resolveFile(name, scope) method, and doing
away with findChild() and FileSystemManager.findFile(baseFile, name).

I might also rename FileName.resolveFile(), FileObject.findFile() and FileSystemManager.findFile()
to the same name, something that indicates that it is simply resolving the name, not actually
searching for the file.

> In FileContent why do you have an "encoding" attribute and how do 
> you imagine 
> it retrieved for a file. Personally it seems to me that and the 
> FileReader 
> may be a littl emisplaced as it is not possible to determine the 
> encoding of 
> the file from most file system types.

I think you're right.  I've seen some horrendous things done in the name of "supporting" non-ASCII
charsets, and the dream was that the FileObject could just take care of it all under the covers.
 However, I don't think that's going to happen.  I might axe the encoding, reader, and writer
methods, and simply expose the encoding - when it is known - via getAttribute().

> In FileContent lastModifiedTime is represented as a Date rather 
> than a long. 
> wouldn't it be more efficient to work with longs?

Yes, of course.  Not sure what I was thinking there.

> How do you do a rename?

Well, you wait for the second cut, when there will be methods like FileObject.move() and FileObject.copy().
 Or you can send me a patch (with test cases please) :)

> The 2 arg findFile() in FileSystemManager seems out of place - 
> why dont you 
> just directly resolve name against basefile?

Again, it's to control scope.  FileObject.findFile() will only find files in the same file
system as the file, so you can't pass it things like absolute URI.  If you know that the name
is relative, you can use FileObject.findFile(), and it will make sure.

FileSystemManager.findFile() will find files in any file system.  You use this if you don't
know what the name is (e.g. something from a build file).  The 2 args version allows you to
specify the base file to use, if the name happens to be relative.

Again, it might be worthwhile to replace the various implicitly-scoped find methods with a
single explicitly-scoped method.

> The FileSystemManager also seems a bit of a misnomer because it 
> represents 
> the root of a file tree. So maybe just FileSystem would be a better term?

At this stage, yes.  The plan was to add management type stuff to it - the ability to create
and attach file systems, etc.  Besides there's a FileSystem interface in the provider API,
and I was too lazy to think up a new name for that.

> Also what other attributes do you think we could apply to trees?

MIME type, is the only thing that comes to mind.  Might be handy to use when deciding to do
<fixcrlf> or filter a file.

Then there's things like permissions, owner, executable flag, etc, which might be best done
as attributes, rather than abstracting out a model for them.

I guess attributes could be used for anything where the provider has to be involved, but which
is rarely used, and is not worth cluttering the FileObject/FileContent interfaces for.

Maybe capabilities as well, though I think that would be better exposed via an interface.

> I would like to keep getBaseDirectory() and resolveFile() for now because 
> tasks could be used in places where a VFS is overkill.

Sure, but what happens when the base directory isn't a local file?

ant -f cvs:// -Dbuild.dir=file:./build

> Maybe the best way to expose this and other services to tasks is 
> via adding a 
> method to the context such as
> Object getService( Class clazz );
> SO you would do something like
> final FileSystemManager manager = 
>   getContext().getService( FileSystemManager.class );
> That way we can remove Composable/ComponentManager from tasks 
> where it was 
> kinda overkill.

Sounds good.

> > * Port FileSet and Path to use FileObject and friends, rather than
> >  Would involve pushing some of this stuff behind the API.
> I woul dbe interested in seeing how you plan to do this.

Something like:

* Refactor <fileset>, similar to <path>, to clean it up and get it working with  Probably extract an interface for <fileset> and <path> to share,
as most tasks simply need a set of files, and could just as easily take a <fileset>
or a <path> (or, say, a <java-runtime> or a <file> or a <swing-file-chooser>).
 This was going to be the starting point for playing with type substitution.

* Move <fileset> and <path> (and the related classes) to org.apache.antlib.<somewhere>.
 Any thoughts where?

* Move PathTokenizer behind FileSystemManager, make it multi-namespace aware, and expose it
via a name parser interface.

* Add some way to convert from FileObject -> local file name.  First cut would simply assert
that the FileObject actually is a local file.  Conversion for other file types (whatever that
means) would be added later.

* Gut Path, FileSet and DirectoryScanner, and reimplement using FileObject.  Would mean the
setter methods would take FileObjects.  The old methods Path.list(), DirectoryScanner.getBaseDir(),
etc, would convert the result -> local file name.

* Add new methods which return FileObjects, such as FileObject[] Path.listFiles() or FileObject[]

* Start porting tasks to the new interfaces and methods.

* Eventually move DirectoryScanner behind FileObject, and get the providers involved in the

> > * Port <move>, <copy>, <mkdir>, <touch> and <delete>.
> some of this
> > stuff would end up behind the API.
> kool. Until VFS is completely up and running it may be best to fork those 
> tasks in myrmidon and then when the VFS is stable just remove the old 
> versions?

Sure - how about into package org.apache.antlib.file?

> > * Look at things like configuring file systems in the build 
> file, getting
> > user name and password from the user, etc.
> How do you think this should happen ?

For starters, it can all be stuffed into the URI:

<copy todir="ftp://user:password@somewhere/pub/libs">
    <fileset dir="build/libs"/>

I haven't really thought about the how, but here are the sort of things it would be good to

* The ability to get the user-name and password from the user's preferences, or prompt for
them, if not specified in the URI.

This is kinda do-able already with a properties file and ${username} and ${password} properties,
it would be nice to streamline it, and not force the passwords to be in a file.

* A way to configure a file system with properties, rather a URI:

<property name="releases-fs">

<javac ... >
        <fileset dir-ref="releases-fs" includes="some-product/lib/**"/>

* A way to create layered file systems in the build file:

<!-- Create a tar fs on top of a gzip'ed FTP file -->
<property name="dist_file">
        <gzip-file file="ftp://server/pub/releases/someprod.tar.gz"/>

<!-- Create a virtual fs -->
<property name="dist_image">
       <fileset prefix="/bin" dir="src/scripts"/>
       <fileset prefix="/lib" dir="build/lib"/>
       <fileset prefix="/doc/api" dir="build/javadoc"/>

<copy dir-ref="dist_image" todir-ref="dist_file"/>

> > a concurrency model, etc.
> shouldn't we delegate to the underlying provider?

Sure.  The question would be what the provider has to guarantee to support, and what is optional.
 E.g. Should it guarantee to detect concurrent read and write?  Is it just a nice thing for
it to do?  How about dealing with files that have more than one name (case-insensitive, links,
aliases, etc)?  Should it consider these the same file when doing the detection?

An eventing system would also fall under the 'concurrency model' topic, I guess.


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

View raw message