ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Lévy-Lambert <anto...@apache.org>
Subject Re: Ant 1.7
Date Wed, 18 Feb 2004 13:39:21 GMT
Matt,

pay attention that most of our tasks - even if you add some 
introspection magic - could not work with something different from the 
current filesets.

a lot of tasks, say <copy/>, <move/>, <replace/> ... are very file 
orientated.

It is not enough to have vfs-filesets or something like that, you need 
to have the corresponding selectors, and the vfs-filesets need to have 
their own *embedded and hidden* scanning system.

I would not change FileUtils to make it support exotic resources on top 
of file system.

It is illusory to think
that you can *without deep changes* make <move/> or <copy/> process sets 
of resources coming from say an HTTP site or a cvs repository.
With Stefan Bodewig, we fixed some problems in the <zip/> task, which is 
one of the only tasks which supports zip entries as a data source, and 
what we did works but is laborious and does not look like
a beautiful design with a great future.

The limitation in the current fileset/ ... types is that the scanners 
(DirectoryScanner) are built as public classes outside of the filesets, 
and you need to separately construct a directory scanner and set it up 
to do something with a fileset.
Then you access the files *knowing that they are files* because the 
scanner gives you their path relative to the root directory of the fileset.

As Conor McNeill wrote once, the scanning code should be hidden inside 
the FileSet (or FileList or whatever) and the FileSet should maybe have 
a method scan(), and then methods to get instreams or outstreams to the 
resources present in the sets.

So in the current ant tasks, there is a lot of code which can only deal 
with Java.io.File and nothing else.

And we must take our time to design more general APIs. The best thing 
would be to do it in a sandbox with a big shield on the sandbox "Warning 
- works here - no backward compatibility guaranteed" so that the guys 
developing there can experiment freely different designs.

Antoine

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message