Sorry all for the long post, bear with me... --- Antoine_Lévy-Lambert <[EMAIL PROTECTED]> wrote: > 4) think about virtual file system abstractions, and > do something about > them, > Since this virtual file system stuff is a biggie, it > should be thought > of and discussed upfront.
Antoine, I am astonished at this "convergent evolution"... :) I have spent many an hour this weekend thinking about VFS, and was planning to make a post specifically about it today. As many may recall, I have been interested in this for awhile now... > > 0) discuss which APIs/Projects ... represent the > kind of virtual file > system we are interested in. I am always thinking > about jakarta > vfs-sandbox (that I only know by name), but one > could also think about > JNDI as an interface through which ant could get > access to a number of > different realms, and there are certainly other APIs > and or > implementations which can be interesting. > I have only really looked at VFS as that is what we have been talking about on the list for the most part. I guess there are different ways we could go. Something I had been considering to some degree for adding VFS in particular would be to consider all VFS-support to live in a single antlib, with whatever that might necessitate. I had considered, for several reasons, that for integration purposes we might use typedefs with adapters to convert virtual filesets to o.a.t.a.types.FileSets and back--is it currently possible to use a type as its own class if available, then adapt if possible instead? One of the first things I had considered this might imply, and perhaps fairly convenient to implement, is pluggable FileUtils implementations. Since a FileUtils object is obtained by a static call, this might not be too bad. Does anyone have any ideas on nice, clean ways an antlib might plug into something like this? Maybe just setting a property and throwing a BuildException or at least logging a warning message in case of failure (>1 competing antlibs tried unsuccessfully to coexist). Anyway, this way tasks could to some degree be converted a bit at a time. Or, an antlib could register its own tasks to override the default tasks (is that possible today?). > I) develop ant virtual filesystem support only in > the vfs sandbox(if vfs > sandbox is chosen in phase 0, that is to say), > without changing ant, VFS is a sister project (or niece, now)... so that's nice (or nepotism?)... or, maybe we don't need to choose, merely abstract certain things (Files mainly) and provide handles to register utility implementations. Probably a FileUtils instance needs to do just about EVERYTHING related to files... obtaining i/o streams, etc... (indirection = overhead?) Another thing to consider is that if we simply choose VFS, perhaps it becomes the point from which to handle JCR/JNDI/etc... it also means we don't have to abstract File as they've already done it, but it also becomes a dependency, most likely, and a sandbox dependency at that... > II) create in ant core some new interfaces > (VfsFileSet and VfsSelector > for instance - also depending of phase 0), make a > critical number of > tasks such as <copy/>, <move/>, <zip/> ... accept > VfsFileSets on top of > FileSets depends on the design we choose... > To my opinion, scanning should be part of the > VfsFileSet interface. It Or of a FileUtils implementation, +0 -Matt __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
