ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dino Valente <>
Subject Re: Including other antfiles
Date Fri, 11 Aug 2000 15:31:34 GMT
At 10:45 AM 8/11/00 +0200, you wrote:
>>>>>> "DV" == Dino Valente <> writes:
> DV> They had this originally but changed it for 1.1. Check other
> DV> emails for the "official" response.
> DV> The general reaction has been: Ant is not make and if you want it
> DV> then implement it yourself
>I hope this two sentences are not related or I'd like to see which one
>came through as the "official" response. And don't take this as an
>official response either, just talking for myself - didn't think I'd
>ever need a disclaimer like this.

When I see a number of Ant developers posting to the user group with the
same response I gather it is official since you have the most say on the
direction of ant.

>You will usually earn a response like this if you want to add
>procedural logic, loops, switch and so on. The same holds true for
>XSLT like template matching.

However, after discussing the issue a lot and narrowing down what is really
useful we can arrive to a satisfactory conclusion (eg the include
discussion). Even issues such as loops, switch etc shouldn't be dismissed
right away. For example loops: In the most programming form, loops seems
too makish and constrary to Ant's direction. However, one could argue that
we don't really want a loop per sue, but we want the ability to traverse a
list of values and execute the same task for each value defined in the
list. Ant (like it or not) is a replacement for make to compile java

>I don't want to get deeper into this because this is not something
>that has been different at some point, so you cannot be talking about
>these issues.
>One of the biggest problems seems to be that people switching from
>make to Ant try to use Ant much the same way they've been using
>make. But Ant uses a very different approach and using Ant to build a
>project out of tens of sub projects controlled by a master file (but
>they still can be built individually) doesn't fit very well into Ant's
>view of the world.

Yet, with the simple ability to include build files and fixing the property
issue we are now able to achieve this very nicely with Ant.

>What has been different, was the handling of properties - and I agree
>that this makes using sub builds a lot more difficult than they need to
>I posted a summary titled "Why properties became immutable" on ant-dev
>shortly after I realized how much confusion the change has caused -
>personally I hardly realized the change.
>I don't want to bore everybody by reposting this article, send an
>email to to get it or
> to get the whole thread with
>some added opinions and minor corrections.
>There are chances that most of this stuff is going to change
>(properties and ${} evaluated at runtime, only a subset of the parent
>project's properties override those of sub projects) - just don't hold
>your breath.

It is great that we can discuss these issues and contribute towards the
direction of Ant. Please, be patient with people like me who persist a
little bit on issues you don't quite agree with. Force us (as you have) to
narrow down the problem and (hopefully) convince the Ant community that the
feature is needed.


View raw message