ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: <available> task
Date Tue, 24 Apr 2001 14:27:24 GMT
Diane Holt <> wrote:

> --- Stefan Bodewig <> wrote:
>> Diane Holt <> wrote:
>> > Is there a reason why the <available> task couldn't be changed to
>> > work at either the project-level or the target-level, the way
>> > <property> can?
>> What's special about <available> to make this change?
> What's special about <property>?

Touché. 8-)

> I think any task whose purpose is just to set something probably
> should be available at the project-level (<filter> and <tstamp> are
> the only other ones I can think of) -- or none of them should
> be.

<uptodate> as well.

Allow everything that changes something internal to be placed outside
of targets and force everything that changes something external into

Sometimes this is difficult to decide, which category does <record>
belong to? Where do we put <script>?  I'm more leaning towards an all
or none approach.

That <property> and <taskdef> may be placed outside of targets can be
explained (like everything else) with "historical reasons".  I think
<property> really was not a task in James' first designs.

> For the future, it could be one way to determine scope, rather than
> going with an attribute to specify that.

Well, we'd need to define which scopes we want before we make a
decision on this.  Do we have file-scope and project-scope, do we have
an even more hierarchical view of the world (scope is this file and
all invoked subbuilds but not the parent build)?

Even if we end up with a total of two scopes, I think I'd still prefer
something explicit like an attribute - or even two different elements.

>> As soon as importing stuff from other build files or even
>> inter-build-file dependencies would come into the mix, we'd really
>> put ourselves into trouble.
> What sort of trouble?

If a target in build file A depends upon a target in build file B, are
the tasks living outside of any targets in B going to be executed?
Which tasks living outside of targets do we execute first, A's or B's?

I realize we already have this problem with properties and taskdefs
(and Conor already addressed this with his initial -1 on the
inter-file dependency request).  If we find a solution for the
property problem, it probably also applies to other tasks as well.

So, you've put me back into an "undecided" state - it probably depends
on further discussion and implementation details for Ant2.  

I'd hesitate to change Ant 1.x semantics now, given that it might
change again in Ant2.


View raw message