>>>>> "sr" == rubys <[EMAIL PROTECTED]> writes:
sr> I just committed a patch which restores the ability to define
sr> properties and taskdefs outside the scope of any target.
sr> Such definitions are processed in the order that they are found,
sr> and prior to any target, but otherwise behave exactly as if they
sr> were included in a target.
Isn't that _exactly_ the same behaviour then?
Property and taskdef tasks do their job in their init method not in
execute which means they are "executed" whenever the parser finds them
- in the order they are found and prior to any target even if they are
defined in targets. Am I wrong?
Defining those outside any targets just makes this clearer. Maybe the
use of property and taskdef tasks inside of targets should even be
deprecated because of their side-effects?
Personally I'd prefer binding properties later - during task execution
not parsing that is.
<target name="init">
<property name="test.prop" value="1" />
</target>
<target name="init2">
<property name="test.prop" value="2" />
</target>
<target name="test" depends="init">
<echo message="${test.prop}"/>
</target>
should result in 1 being echoed not 2 - and null if test didn't depend
on init.
Stefan
