> -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > In the case of <antcall> I pretty much doubt it would be too useful as > you could always add the if/unless attributes to the target you intend > to call. Granted, you'd save the memory hit of reparsing the build > file when you could know that it won't do anything, but that's pretty > much all, no?
No, you can't really do that because if/unless tests for a properties existence. How would you *not* pass a property using <param>? It's either there or not. If you meant to set a global property that the callable task is dependent upon, that wouldn't work either because once the property is set, it's set... How would a different invocation invoke/not-invoke the task? > The main reason against "all tasks" is that people would immediately > start to overuse it and create incredibly complex build files that > most of the time could have been written cleaner without those > attributes. I agree, if/unless on <property> makes no sense. I'm only talking about <antcall>. IMHO, <antcall> allows developers to write 'callable' tasks. Without some 'callable' tasks, your build file will look like it's from rape-and-paste hell. I see <antcall> allowing me to write certain repetitive tasks once-and-only-once. If it's not desirable to use <antcall> in this way, could someone give me an example of how <antcall> can be used more appropriately? Thanks, Michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
