[Suggetions 1 and 2 are related to integrating Ant with other packages, e.g. IDEs.]
(1) Ant should be cancellable. It should respond gracefully to cancel requests, when running in a background thread. As explained in http://gee.cs.oswego.edu/dl/cpj/cancel.html, the only really good way to cancel something running in a thread is for it to periodically check for cancel messages. Ant should do this. (2) Key methods which provide base services should be publicly accessible. For example, the pattern-matching methods of DirectoryScanner are currently not easily accessible to outside code. If you wanted to, for example, build a TreeModel that displays the contents of an Ant fileset, you need to be able to access these methods. (3) The default output should be clear, informative, and terse. A new build that completes successfully should output a small number of lines; a build that is already up-to-date should output even less. The default output should be easily parsable by the most common editors, so the user can jump to the problem line. A build failure should visually be very distinguishable from a successful build, so it's easy to tell at a glance whether the build failed or not. (Specific suggestions/pet peeves: Save all-uppercase messages for build failures. It should not say "Compiling 183 files" when in fact all these files are up-to-date, so no files will actually be compiled.) [Trying to be as non-controversial as possible here...] (4) Ant should provide enough support that a scripting language can be implemented as a task. These scripts should be able to easily call through to other tasks to perform the actual work. This should include support for XML-based scripts. I think this means, among other things, that a task will need to be able to get at its XML (i.e. the portion of the build file that describes it). (5) It would be nice if there were a semi-standard XML-based scripting language for use with Ant (but not part of Ant core). This is because many people seem to want to write Ant files with XML-based scripts in them (as evidenced by the many posts to this list), and if people are going to be doing this, they might as well be using a common language. This scripting language (task) might be special in that it is bundled with the core Ant (the code, doc, and samples), or it might simply be referenced in the doc. Hopefully it can be something that's not invented here, but if nothing suitable exists it could be Ant-specific. (Of course, anyone can write a task to use any language they want at any time.) Thanks! Alex Rosen SilverStream Software --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
