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 Mon, 21 Jan 2002 10:11:54 GMT
On Sun, 20 Jan 2002 17:53, Adam Murdoch wrote:
> > 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) :)

For me to send a patch you would first need to send the source ;)

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

Okay - I think I am lost again ;)

Is FileSystemManager a single tree (ie "C:\"), a single type (ie "file:") or 
a system-wide service. If it isn't the last I am not sure that the findFile 
should be able to cross different namespaces/filesystems.

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

I would move them to org.apache.antlib.framework.* because they will most 
likely want to be used by multiple applications. 

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

works for me - or maybe org.apache.antlib.vfile

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

I think this should be done with properties and a separate <prompt /> task or 
similar? Thoughts. We already have an <input/> task in ant1.x, this could be 
generalized for loading more properties or something

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

I wouldn't bother with concurrency detection as such - I would just make sure 
that the in memory representation is consistent and the underlying provider 
API semantics are maintained (which would mean blocking for certain requests 
over ftp for example).



 We shall not cease from exploration, and the 
  end of all our exploring will be to arrive 
 where we started and know the place for the 
        first time -- T.S. Eliot

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

View raw message