ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Ant2 VFS Proposal
Date Sat, 19 Jan 2002 15:41:16 GMT

Looks good so far. A few questions

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

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.

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

How do you do a rename?

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

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?

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

On Thu, 17 Jan 2002 22:07, Adam Murdoch wrote:
> The goal for this first cut was to do up a proof-of-concept.  I'd love to
> get some feedback from ant-dev.  The javadoc for the API interfaces is
> attached (I've left out the provider API, cause it's just noise at this
> stage).  Please have a read - comments most welcome.  Just keep in mind it
> ain't finished yet.  If it looks ok, I'll tidy-up the code (license,
> package names, etc) and send it in.

sounds good to me :)

> The next step would be to try it out.  I'd like to do this in Myrmidon, if
> possible.  The plan would be something like:
> * Do up a FileSystemManager impl that wires into myrmidon.


> * Expose the FileSystemManager to the tasks via TaskContext as (ultimately)
> a replacement for getBaseDirectory() and resolveFile().  Could be done via
> ComponentManager + AbstractTask too, I suppose.

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

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.

> * Add a String -> FileObject converter.


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

> * Port <move>, <copy>, <mkdir>, <touch> and <delete>. 
Again, 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 

> * 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 ?

> * Get the FS providers involved in searching, deleting, moving, and
> copying. Do as much as possible of this remotely.


> * Layered FS, compound FS, filtering, 


> a concurrency model, etc.

shouldn't we delegate to the underlying provider?



Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982

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

View raw message