Ken Wood wrote:
It was designed to be a JAVA program to build java. It was designed to be extended using java because that was the original CONCEPT
Have you talked to the original author? I have.
The original concept was language independent. The implementation and the first set of tasks were written in Java because that's what James Duncan Davidson needed at the time.
James, Stefano, myself or the others at the time would have no objections to Ant being extended by COBOL or LISP or whatever.
What everybody didn't want was for the Ant language itself (by this, I mean the XML grammar) to become yet another programming language.
In my opinion, all of the built in tasks provided by Ant *DO* define a programming language of a sort. At various times in the past, I've asked for a way to define tasks within ant itself.
For example, I have a fixed set of operations that I do to build tools for JShell, that I encapsulate in a simple build script, buildtool. Now, I can probably execute this by just using the <exec> task, and running my original script, but then I lose the power of using ant to control compilation, etc. What I've asked for in the past is the ability to define compound tasks, built from existing tasks. So, my buildtool task would be made up of <javac>, <jlink> and <copy>. Given this capability, abstraction, Ant truly becomes a programming language, and why be against that?
If I can also build task definitions using scripts, then so much the better. Why not allow as many extension mechanisms as possible?
- Patrick --
// Patrick C. Beard // Java Runtime Enthusiast -- "Will invoke interfaces for food." // mailto:[EMAIL PROTECTED]
