ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: Ant 1.7
Date Mon, 16 Feb 2004 15:51:41 GMT
Sorry all for the long post, bear with me...

--- Antoine_LÚvy-Lambert <> 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


Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.

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

View raw message