ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Lévy-Lambert <>
Subject Ant 1.7
Date Mon, 16 Feb 2004 14:03:20 GMT

I do not know if we will make some further releases of ant 1.6. My guess 
is that there might be from time to time the need for a release due to 
"environmental factors", such as the release of a new version of an 
operating system forcing us to adapt the famous Os class, or some 
problem of the type of the javah entry point, ...

In any case I am starting to think about ant 1.7 and further.

Here are the points which spring to my mind :

1) local properties,
2) roles,
3) get the xdocs proposal out,
4) think about virtual file system abstractions, and do something about 
5) fix some popular bugs from bugzilla

I plan personally to work on 3) (getting the xdocs proposal out).

I have the feeling that it might be better to use xml-forrest (like an 
increasing number of Apache Projects) for our static xdocs and for our 
manual, rather than anakia for the static xdocs and dvsl for the manual.
Ultimately, the look and feel of the welcome page or of the faq page of 
the ant web site should be the same as the look and feel of the manual - 
although with xml-forrest users have the possibility of generating the 
manual with another look and feel if they want to.

Although it may not sound like a big thing, I believe there is a lot of 
work to get xdocs stuff finished. Work concerning :

     - the way the data is extracted from the source code (I am not sure 
whether the current antdoclet can also work to get data out of *types* 
instead of tasks),
     - the formatting of the xml extracted from the source code (for 
instance the xml-forrest config files, ...)
     - of course and most importantly the content itself,  notably the 
static merge files containing the examples, ....

Concerning 4), I do not think I am going to have time to take care of it 
personally soon.

Since this virtual file system stuff is a biggie, it should be thought 
of and discussed upfront.

I see 3 phases :
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) 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,

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

To my opinion, scanning should be part of the VfsFileSet interface. It 
was an error in the first place to separate scanning from the resource 
sets which are scanned (at least in public interfaces).

Phase I is a good first step to play with the vfs concept and find out 
its limits and potentialities. The advantage of the corresponding time 
is that it is a play time where there is no danger of breaking ant.
But during this phase, the vfs will also appear as something exotic 
which cannot really be used.
To get vfs out of the door,  phase II will be necessary. But we will 
need to know what we are doing then, so that we introduce new interfaces 
which are generic enough to support a large number of implementations 
and use cases, and precise enough to be really useful.

Very long term, if we were to get something really good, it might be 
possible to change the axiom saying "Ant only builds based on  JDK + XML 
parser" to "Ant builds with JDK + XML Parser + VFS API".


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

View raw message