ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject Re: init targets
Date Sun, 17 Dec 2000 08:04:26 GMT

----- Original Message -----
From: "James Bucanek" <>
To: <>
Sent: Saturday, December 16, 2000 7:41 AM
Subject: Re: init targets

> At 12:00 PM -0800 12/15/00, Diane Holt wrote:
> >I think pre-1.2, "init" was a special target that executed at start-up. If
> >the documentation still suggests that's the case, then the doc should get
> >updated (if you're so inclined, you can do that and submit a patch-file :)
> No, the docs aren't wrong, just a little vague.  What caught me out
> was the statement in the TStamp task that stated:
>      The best place for this task is in your initialization target.

There used to be a special target called init which if present would be executed before any
others. I didn't like it at the time
because it was such an arbitrary convention. In other words there was a special target name.
The specialness of the target was not
evident from the structure of the build file. You had to "know" the special name. I think
it was necessary at the time because
properties could not be set outside of a target at that time.

OK, so your proposal addresses that somewhat by naming the init target as an attribute of
project. Nevertheless, I still don't
really like it. If that target has a depends clause, what does that mean. Should those targets
be evaluated before the init target.
That seems to violate the contract of the init target. If you wanted to go this route, then
I feel we would need to have a separate
<init> element which functions somewhat like a target but without the depends, if, unless,
etc clauses. Then the special nature of
the target is part of the build file structure and sensible behaviour, such as no depends,
is dictated by the structure and not

It is similar for an onfailure target. What if it has depends? What if it fails?

Also, adding feartures and then allowing them to be disabled is OK for a small number of features.
After that it becomes combersome
and can be seen as an attempt to please everyone. Optionality is not always a good thing.

I am not trying to discourage you from pursuing this, but I think you really need to think
it through fully both in terms of build
file structure (new elements) and the necessary processing.


View raw message