> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > 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://cvs.apache.org/jakarata-ant/build.xml?tag=ANT_2_1 -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 > > 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? * 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[] DirectoryScanner.getIncludedFiles(). * Start porting tasks to the new interfaces and methods. * Eventually move DirectoryScanner behind FileObject, and get the providers involved in the scanning. > > * 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? > > * 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:[EMAIL PROTECTED]/pub/libs"> <fileset dir="build/libs"/> </copy> I haven't really thought about the how, but here are the sort of things it would be good to add: * 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"> <smb-filesystem host="somehost" share="someshare" use-local-account="true" read-only="true" root-dir="/somedir/releases" /> </property> <javac ... > <classpath> <fileset dir-ref="releases-fs" includes="some-product/lib/**"/> </classpath> </javac> * 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"> <tar-file> <gzip-file file="ftp://server/pub/releases/someprod.tar.gz"/> </tar-file> </property> <!-- Create a virtual fs --> <property name="dist_image"> <virtual-file-set> <fileset prefix="/bin" dir="src/scripts"/> <fileset prefix="/lib" dir="build/lib"/> <fileset prefix="/doc/api" dir="build/javadoc"/> </virtual-file-set> </property> <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. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
