Diane Holt <[EMAIL PROTECTED]> wrote: > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: >> Diane Holt <[EMAIL PROTECTED]> 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 targets? 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. Stefan
