ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: new Task subclass
Date Mon, 26 Jul 2004 15:48:04 GMT
OK, I been giving some more background thinking on this issue.

And at this point, I cannot find any reason why to use Xpath
as the language for condition evaluation. The reason being that
on most builds (if not all) how the execution flow goes does not depend
on how the XML build file looks like but on external factors
"Is such class available?", "Are this files uptodate?", "Is this file
bigger that that one",
"Is the value of this property the same as this or that?"

So I fail to see what good does it do to use a language designed to
talking about the structure of a document (attributs and elements) where
that is the least of our concerns.

With this in mind, I have been thinking on Velocity as a better glue for
language. The idea being to provide access to the current conditionals
via the Velocity context, for example, and hence allow callong them from

Velocity. The context will provide a bridge between the Velocity syntax
and the most common conditionals by means of, for example, velocimacros.

I am also thinking on Conditionals providing a subinterface that allows
simpler glueing into the evaluation engine. So we would be able to say
something like:

	if="${cond: $available.att("file",
${myFile}).att("type","file")}" or
      if="${cond: $available.file(myFile).type("file")}"

or something like that. This will require us going ahead with addig
roles to
the context know what conditionals are out there.

Comments, thrashing, refining, how to's?

Jose Alberto

> -----Original Message-----
> From: Phil Weighill-Smith [] 
> Sent: 22 July 2004 12:22
> To: Ant Developers List
> Subject: Re: new Task subclass
> 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.
> 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.
> 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.
> Phil :n)
> On Thu, 2004-07-22 at 11:47, Stefan Bodewig wrote:
> > On Thu, 22 Jul 2004, Jose Alberto Fernandez 
> > <> wrote:
> > 
> > > As per if/unless itself, I really would like to explore more what 
> > > some people have suggested about having a richer language 
> than just 
> > > set/unset.
> > 
> > PropertyHelper?
> > 
> > IOW, I think we already have the infrastructure needed to 
> do that in 
> > Ant's core.
> > 
> > Stefan
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> -- 
> Phil Weighill-Smith <>
> Volantis Systems

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

View raw message