ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ludovic Claude>
Subject Re: ANT semantics and power
Date Mon, 28 Feb 2000 23:05:07 GMT
William Uther wrote:

> Hi all,
>   As has now been noted a couple of times, there are two issues here.  One
> is ANT's basic semantics and the second is how powerful the language is
> made.
> I think it is quite clear that ANT has a large procedural component: it
> takes a sequence of tasks and execute()s them in a specific order.  It is
> interesting because there are multiple orders depending upon the type of
> task executed.  Assignment statements are executed first, and in a
> different order to all other statements. [...]

Very good example, and you could add something like

<project name="Test" default="main" basedir=".">

  <target name="neverRun">
    <echo message="neverRun is running"/>
    <property name="hasRun" value="NeverRun has Run"/>

 <target name="main" depends="myInit">
    <echo message="main is running"/>
    <echo message="${hasRun}"/>
    <echo message="${inited}"/>
    <ant antfile="Test.xml" target="subproject" >

  <target name="myInit">
    <echo message="Init is running"/>
    <property name="inited" value="I've been inited"/>

  <target name="subproject">
    <echo message="Subproject running"/>
    <echo message="${hasRun}"/>
    <echo message="${inited}"/>


and Ant currently produces:
Init is running
main is running
NeverRun has Run
Subproject running
NeverRun has Run
I've been inited

where you would expect after a few years of procedural / object programming:
Init is running
main is running
I've been inited
Subproject running
I've been inited

The only declarative aspect of Ant is the way the targets are processed - and
that's what
gives it power, yes!, but the rest looks plain procedural programming to me.
And the way
properties are processed is really disconcerting...

> Another possible solution is to move all property setting out of the
> targets.  This removes the expectation that it will be executed in 'target
> order'.  I gather from one of the recent posts that this is the way things
> once were and this might explain the current strange semantics.

Maybe, but with the lastest post you cannot define anymore things outside a
Or following Costin's sugestion, you explicitely rename property as constant,
and you
force ant to find a target called 'init' that contains all constants. And while
you are here,
make everything constant, including filters, and remove the ${name} syntax that
this whole discussion to start...

The real problem here is what do the user want? Personally, i've never managed
to use make,
so if you tell me that by implementing dynamic properties, nested tasks and so
on, i'm doing
nothing but re-implement make, ok i stop here. But my problem is that i want to
use Ant for
all my build/test/deployment tasks, and i use java, jsp, rmi and so on (no
compilation of native
code here), and i want version-control, archiving, deploy my code on the
servers and so on.
I have now 20ish build and install scripts based on ant, and i think i've seen
the power - and limitations- of ant. For me, the perfect ant would have a core
of powerful tasks solving most of
the problems encountered by java developers, but yet flexible enough to solve
those exceptional
situations that you have in real-life projects. And i like to write things in
Java when they can
be used and reused, but for one-shot problems I prefer to use a scripting
language. So sure,
you can say code your own tasks in java for your specific problems, but so why
do we use
this build.xml file? It could all be plain java...

>   I am intrigued by ANT being called a declarative language.
> <> defines a
> declarative language as follows:

Perfectly right!
Who wants to make Ant a Prolog-like language? or like PDF? (what can you do
anyway with PDF)


Web Site Watchers Ltd
212 Piccadilly,
London W1V 9LD

Telephone: +44 (0)171 917 6255
Fax: +44 (0)171 439 0262

View raw message