> * Allow named tasks to be defined by <script> elements. > > * Support nesting tasks into other elements
+1 > * define task contexts that define various common aspects (logging, > failure handling ...) and assign them to tasks +1, but lets sort out how this and the "namespace triggers aspect" stuff are going to play together. > * specify an onfail task or target that runs in case of a build > failure. -1, on a target - as this would need special treatment. It wouldn't be allowed to specify an onfail target itself or depend on one that does ... -0 on defining a task for this case. > * allow sequence to be specified in depends attribute or enhance > antcall to work with current list of executed targets > > * provide a way to define the order in which targets a given target > depends upon get executed. This is the same - more or less. +1 I understand the usecase, and actually there are build files that already rely on the current implementation where the depends-targets are processed in sequence. See beanutils in commons for example, there is a clean-build target that would fail miserably if the targets get called in the "wrong" order. I lean towards defining the current way as standard. > * Make if/unless attributes to check for the value of a property, > not only its existance. > > * check for more than one condition in if/unless attributes. -1, don't do this in the if/unless attributes, use <condition> instead. Stefan
