Hi,
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 them,
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 FileSets
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".
Antoine
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
