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
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
