Jon,
> -----Original Message----- > From: Jon Tirs�n [mailto:[EMAIL PROTECTED] > [snip] > > Of course, there are some issues here as well: If a project is called from > another project whould all the failure-targets be run in the chain? If a > task is called from within the same project should the > failure-target be run > several times? Probably not, but what are the semantics? I > imagine it would > be healthy to reuse the same semantics as with ordinary targets, > if it's run > it does not need to be run again... > > Also (for both A and B) could failure-targets have "dependants" > and what if > they fail? > > And, of course, applying the "keep-things-simple" general rule (occhams > razor), is there a way to design this simple enough? ASAP (= As Simple As > Possible ;). > Is that Pandora's box I hear creaking open :-)? If failure targets cannot have dependencies then they are not really targets - they are something else. If they can't have failure attributes then, again, these failure targets are not targets. If you are going to introduce such restrictions then you want something which is not really a target anymore, it is something more like a <failure> element which could contain tasks but not have depends or failure attributes. Conversely, without such restrictions, the complexity goes up, as does the scope for things like infinite failure loops. Thoughts? Conor
