Which would be viable only if the <if/> task wasn't broken. Ant is brittle when dealing with container tasks and ids/datatypes/nested container types...
Every time the debate starts again, and committers start refusing this generalized if/unless issue to save me from shooting myself in the foot, it makes my cringe. If you don't want to use it, then don't. But why refuse it to everyone who wants to use it? Does Ant really want to be swallowed by Jelly? And personally, the if/unless/antcall debate would be moot if the nested <depends target/if/unless> with proper static dependency analysis was introduced, as it would take care of most of the use cases, but again paralysis is striking! The refusal to embrace XML namespace, which are increasingly being used with XML and is a natural fit to partition XML dialect, is not a good sign either. The lack of <antlib> and the multiplication of Ant extension points beyond tasks/datatypes is hurting Ant even more (although Costin and Magesh are working on those, when will they show up in a release? In a year? Two?) Ant is a great collection of tasks, extremely useful, but the Ant core is fast becoming out of date IMHO, and Ant is somehow becoming victim of its success because any change is so excruciatingly difficult to get voted in. Maybe I'm making it more dramatic than it really is, but I love Ant, and I feel it's too stagnant, especially after the debacle of the Ant2 proposals. --DD -----Original Message----- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 4:59 AM To: Ant Developers List Subject: RE: [PATCH] adds 'if'/'unless' to <antcall> (CallTarget.java) If people really need to do contitional things they should just use the <if/> task that comes as part of ant-contrib. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
