ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: new Task subclass
Date Thu, 22 Jul 2004 15:08:47 GMT
Phil Weighill-Smith wrote:
> My vote for a "language" within if/unless elements is to use XPath (1 or
> 2). Pretty powerful and standard within the XML domain! You could even
> think of supporting path expressions that access the entities (targets,
> properties, types etc.) within the current Ant build file and could
> provide some supporting functions that allow tasks and/or targets (in
> the current build) to be invoked or other ant-specific operations to be
> performed.

I am not sure. I disagree because the standards group that I am involved 
in as a day job has been proposing using xpath for its reference model 
within an XML deployment descriptor 
(, and I have concluded 
it doesnt work once
you have a more complex model.

The problem is that xpath paths refers to document structure and not to 
object structure. Now that we have an interitance model (<import>),the 
two are not the same. So if you are trying to refer to targets, xpath 
may be wrong. Here, for example:

<target name="foo" depends="/target[@name='init']">

> To maintain backwards compatibility, all that is needed is a delimiter
> that indicates that an XPath expression is being used. E.g.
> ... if="debugmode" ...
> for backwards compatibility or
> ... if="@call("available", "file", ${file}) == true()" ...
> to indicate that the "available" task should be called with the
> specified property set as the "file" attribute (XPath supports "varargs"
> so having name/value pairs of parameters to define the attributes of the
> invoked task is easy to implement). Explicit functions could be made
> available for the most common task invocations in conditions.

At the same time, we dont want a condition language that is home rolled, 
do we. Which is a strong argument in favour of Xpath, build file 
structure notwithstanding.

> Finally, it would even be possible to drop the delimiter and evaluate
> the expression as an XPath instead of as a property name if there are
> any "illegal" property name characters (such as "(", "/" or whitespace)
> in the expression.

Not even whitespace is forbidden. typeof(property)!=xsd:NCName :)

         <property name="(/) !" value="naughty!" />
         <echo >${(/) !}</echo>

      [echo] naughty!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message