ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
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
> > > java.io.File.  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 java.io.File.  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?

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

-- 
Cheers,

Pete

---------------------------------------------
 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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message