From dev-return-59357-apmail-ant-dev-archive=ant.apache.org@ant.apache.org Thu Jul 22 14:56:16 2004 Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 17315 invoked from network); 22 Jul 2004 14:56:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 22 Jul 2004 14:56:16 -0000 Received: (qmail 69206 invoked by uid 500); 22 Jul 2004 14:56:14 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 69113 invoked by uid 500); 22 Jul 2004 14:56:13 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 69097 invoked by uid 99); 22 Jul 2004 14:56:13 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [212.18.242.163] (HELO leeds.cellectivity.com) (212.18.242.163) by apache.org (qpsmtpd/0.27.1) with ESMTP; Thu, 22 Jul 2004 07:56:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: new Task subclass Date: Thu, 22 Jul 2004 15:56:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new Task subclass Thread-Index: AcRv4blwOf7QAwHJSA+Y1pXznD9W4gAFkv5A From: "Jose Alberto Fernandez" To: "Ant Developers List" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > From: Phil Weighill-Smith [mailto:phil.weighill-smith@volantis.com]=20 >=20 > My vote for a "language" within if/unless elements is to use=20 > XPath (1 or 2). Pretty powerful and standard within the XML=20 > domain! You could even think of supporting path expressions=20 > that access the entities (targets, properties, types etc.)=20 > within the current Ant build file and could provide some=20 > supporting functions that allow tasks and/or targets (in the=20 > current build) to be invoked or other ant-specific operations=20 > to be performed. >=20 No issue on allowing Xpath, in particular because we probably are shiping implementations of it inside the parsers or xslts and maybe one can get hold at them.=20 Which means is close to enough to core. But I would like to limit it to more or less what we can do with conditions I do not think we are looking for some new syntax for executing ANT tasks. :-) > To maintain backwards compatibility, all that is needed is a=20 > delimiter that indicates that an XPath expression is being used. E.g. >=20 > ... if=3D"debugmode" ... >=20 > for backwards compatibility or >=20 > ... if=3D"@call("available", "file", ${file}) =3D=3D true()" ... >=20 If we were to allow property expansion of if/unless, you could just say something like: ... if=3D"${Xpath: call("available", "file", ${file}) =3D=3D true()}" ans as Stefan pointed out an Xpath PropertyHelper will take care of it. There is still the issue of what if/unless finish testing. > to indicate that the "available" task should be called with=20 > the specified property set as the "file" attribute (XPath=20 > supports "varargs" so having name/value pairs of parameters=20 > to define the attributes of the invoked task is easy to=20 > implement). Explicit functions could be made available for=20 > the most common task invocations in conditions. >=20 > Finally, it would even be possible to drop the delimiter and=20 > evaluate the expression as an XPath instead of as a property=20 > name if there are any "illegal" property name characters=20 > (such as "(", "/" or whitespace) in the expression. >=20 Illegal characters? We have been so liberal I do not thing there=20 are more illegal things :-) But seriously, I do not like these shortcuts, because they will hit us tomorrow when we try to add something and NOOOOOOO you cannot do that because Xpath kicks in on that syntax.=20 BTW, something I forgot from my original set of arguments: - Today if/unless are defined as regular attributes of tasks/targets which means those task/targets are the ones that deal with it. - Instead, you could think of them as meta-attributes available on ANY element and which is evaluated by ProjectHelper itself. Or something like that. That would mean, that you could write not only conditional tasks, but also conditional subelements of tasks, everywhere. Today very few tasks support such thing the exception being = . So, that is another alternative which may give a lot of power. Maybe too much? ... Hey this is a conditional if!!! :-) but no way to write else :-( Notice that will not be modified at all, because eveluation occurs before the task is called. Of course, here we would be free of BC issues, so we could have a freer hand on how would it work. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org