Hi,
your are raising the question : what is ant's mission ?
Our web site proclaims "ant is a make tool without make's wrinkles".
Really ant's core is an engine which can instantiate java objects out of XML project files, and run tasks grouped in targets optionally linked by dependencies.
One can use this engine for a lot of purposes. People developing batch applications can come to the idea of wrapping all their applications into ant tasks.
For instance one could make a build file to manage the accounting activities of a bank which would look like this :
<calculate-accruals/> <calculate-income-statement/> <calculate-balance-sheet/> <produce-summary-for-board/>
If one combines ant with ant-contrib (although I have never used ant-contrib personally), one has probably all or almost all of the control/loop structures which are present in say ksh,
plus the XML format and the extensibility.
Concerning ant 2, I read previous posts saying that the whole idea of a new - potentially incompatible - ant, was discarded, and that incremental evolution with preservation of backward
compatibility is the way to go.
Cheers,
Antoine
Gus Heck wrote:
This thread has somewhat stirred up my brain a bit and a thought that floated to the top goes like this:
We do want to be able to write simple declaritive build scripts for builds. I think this is a major virture of Ant. But clearly when one ventures into the "system of builds" and such there are people who feel they need a more programatic tool. Maybe what is happening here is that we are trying to make Ant do too much... feature creep in essence.
So the interesting (to me) part of the thought I had is this: Perhaps Ant is the tool for defining small declarative builds, or portions of a complex build system, and another more programatic tool should be created to take a series of Ant builds and coordinate them in large projects. While custom tasks are a great tool to have, and that option should always remain open, java is not a scripting language, it is an OO language, and one winds up with a fair bit of OO overhead (that's a fun one to say :) ). It takes some time and effort to learn where to find the things you need to write a custom task (like the use of DirectoryScanner, and the half dozen types of results it creates and the difference between getNotIncludedFiles, getExcludedFiles, and getDeselectedFiles).
Maybe this is the real role for Ant 2? Ant 2 could use Ant 1 builds (or something close that can be autocreated from ant 1 builds) as atomic units, and provide a more comprehensive means of coordinating them, passing properties into them, etc.
We could promote it like like a movie sequel :) "Ant II: The Colony"
-Gus
Stefan Bodewig wrote:
On Wed, 21 Jan 2004, Jan Materne <[EMAIL PROTECTED]> wrote:
http://www.theserverside.com/news/thread.jsp?thread_id=23426
I don't read TSS and haven't followed the article, but Jon is the build guy at ThoughtWorks, Martin Fowler's company. Martin has already blogged[1] about the same issue and my main comment[2] is that it is true. "Complex builds need a real language" and to me the real language is Java - write tasks.
Stefan
Footnotes: [1] http://martinfowler.com/bliki/BuildLanguage.html
[2] http://stefanbodewig.blogger.de/stories/48048/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
