Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
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: Tue, 27 Jul 2004 13:32:01 +0100
Message-ID: <F3D701FEF0483B4AAA11A18CE328461B078221@leeds.cellectivity.com>
Thread-Topic: new Task subclass
Thread-Index: AcRzvNfqPmCS+kq+QEK8wUYUlOXHrwAEj7Rw
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>

> From: Phil Weighill-Smith [mailto:phil.weighill-smith@volantis.com]=20
>=20
> XPath is a language that handles complex expressions that=20
> *can* include document navigation and "query" paths but also=20
> contains a lot of other capabilities (consider what you can=20
> do with expressions in XSLT: these expressions use XPath with=20
> extension functions).
>=20

Xpath is not the only language that allows complex expressions,
you can do the same in Velocity and in many others. I am not talking
at all about inventing a new language, but aabout finding the best fit.

My problem with Xpath here, is that the extension functions are not the
reason for
Xpath and the central point of the design of Xpath, Xpath was design
to address queries on document structures. Now, do we really need to use
a language design for that, or shall we use a diferent one more that
more
closely reflects the kinds of expressions ANT programmers require.

> My suggestion is to have Ant register extension functions with the
> *XPath* context so that they are callable from XPath;=20
> however, in my original message I suggested a single=20
> (standardized) "call" method that can be used to call any=20
> registered Ant task as a catch-all. I also suggested that you=20
> *might* want to invoke a target (for some reason) within the=20
> expression and that this could be achieved using the document=20
> navigation features of the XPath "language" (though what a=20
> return value is from a target I don't know other than=20
> "success" or "BuildException thrown").
>=20

At first sight, I am against allowing the execution of tasks or targets
from within the expression language. For the same reasons that in XSLT
you cannot (easily) apply a template in the condition (test attribute)=20
of a <xsl:choose><xsl:when/></xsl:choose> statement.

It seem to me to be wrong and will unravel the whole of ANT into some
sort
of unmanageble mush. So we need to be very careful of what facilities
we provide, and what things we make not easy for users to try.

Notice that task evaluation is already available, if you really want.
You just need to define a PropertyHelper that uses BSF and then you can
write whatever you like I there. But, I doubt many people will follow
that route.

> Following your example we could register (again as I=20
> suggested) special functions for the "standard" conditionals,=20
> so the expression could look
> like:
>=20
> ${cond: available("file", $myFile, "type", "file")}
>=20
> (XPath variable reference syntax is a bit different from=20
> Ant's property reference syntax: it simply uses a "$" to=20
> prefix the QName of a registered variable: all Ant properties=20
> would have to be registered as variables with the XPath=20
> context/infrastructure in some way, with "illegal" characters=20
> translated into legal ones).
>=20

This is where the impedance of the languages will show up.
I think that with the addition of recursive property evaluation
this issue can be solved in a more elegant and organic way.

> Having thought about it a bit more, it strikes me that we=20
> could have a means of automatically generating appropriate=20
> functions, in the appropriate namespaces (if needed), for=20
> *any* and *all* registered tasks. E.g. a task "myTask" in a=20
> namespace defined for "http://example.org/namespace" with a=20
> prefix of "x" could be automatically provided with an=20
> expression function that would understand the possible=20
> attributes just like Ant does. This would then be callable
> like:
>=20
> ${cond: x:myTask("myAttr", $example)}
>=20
> XPath allows function calls to be nested, so the following is=20
> legal (and easy to implement):
>=20
> ${cond: condition(and(available("file", $myFile),=20
> available("file", $myDir, "type", "dir")))}
>=20
> Finally, functions can also be defined that generate "data=20
> types" other than booleans. That way it would even be=20
> possible to handle nested elements (as implied by the above=20
> example). Another example (this isn't really conditional, but=20
> you should get the idea):
>=20
> ${cond: copy("todir", $myDir, fileset("dir", $fromDir,=20
> include("name", "**/*.java"), include("name", "**/*.jj")))}
>=20
> Following this example it can be seen that the parameters to=20
> the function are either a string (in which case it's an=20
> attribute name and therefore followed by an attribute value -=20
> which must also resolve to a string), or are a data type (in=20
> which case it corresponds to a nested element and has no=20
> following value).
>=20
> (I assume that an expression that uses a task that doesn't=20
> effectively return a boolean value would return true if the=20
> task executed successfully and false if the task threw a=20
> BuildException).
>=20

As I said, I am against invoking tasks/targets on conditions,
this things have by definition side effects which means they
change the state of the build. An this will just produce spaggetti
code of the worst kind.

What I expect of such an expression language, if we deside to have one
(and I am not 100% sure we will), is to be able to do what we can do
with conditions today, hopefully including ANTLIB defined conditionals.

Now that may also involved expressing things like filesets, mappers,
and some other construct required to build conditions. But that,
in my opinion could be done by providing Helpers (EvaluationHelpers?)
simillar to our current InvocationHelper that provides the necessary
glue.

And remember, the fact that I am pushing for Velocity or some other
simillar language, does not disallow having many others including Xpath.
That is the whole point of the PropertyHelper framework.


Jose Alberto

> Anyway, that's my tuppence worth.
>=20
> Phil :n)
>=20
>  On Mon, 2004-07-26 at 16:48, Jose Alberto Fernandez wrote:
>=20
> > OK, I been giving some more background thinking on this issue.
> >=20
> > And at this point, I cannot find any reason why to use Xpath as the=20
> > language for condition evaluation. The reason being that on most=20
> > builds (if not all) how the execution flow goes does not=20
> depend on how=20
> > the XML build file looks like but on external factors "Is=20
> such class=20
> > available?", "Are this files uptodate?", "Is this file bigger that=20
> > that one", "Is the value of this property the same as this or that?"
> >=20
> > So I fail to see what good does it do to use a language designed to=20
> > simplify talking about the structure of a document (attributs and=20
> > elements) where that is the least of our concerns.
> >=20
> > With this in mind, I have been thinking on Velocity as a=20
> better glue=20
> > for this language. The idea being to provide access to the current=20
> > conditionals via the Velocity context, for example, and hence allow=20
> > callong them from
> >=20
> > Velocity. The context will provide a bridge between the Velocity=20
> > syntax and the most common conditionals by means of, for example,=20
> > velocimacros.
> >=20
> > I am also thinking on Conditionals providing a subinterface that=20
> > allows simpler glueing into the evaluation engine. So we=20
> would be able=20
> > to say something like:
> >=20
> > 	if=3D"${cond: $available.att("file",=20
> ${myFile}).att("type","file")}" or
> >       if=3D"${cond: $available.file(myFile).type("file")}"
> >=20
> > or something like that. This will require us going ahead with addig=20
> > roles to the context know what conditionals are out there.
> >=20
> > Comments, thrashing, refining, how to's?
> >=20
> > Jose Alberto
> >=20
> > > -----Original Message-----
> > > From: Phil Weighill-Smith=20
> [mailto:phil.weighill-smith@volantis.com]
> > > Sent: 22 July 2004 12:22
> > > To: Ant Developers List
> > > Subject: Re: new Task subclass
> > >=20
> > >=20
> > > My vote for a "language" within if/unless elements is to use
> > > 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
> > > To maintain backwards compatibility, all that is needed is a
> > > delimiter that indicates that an XPath expression is=20
> being used. E.g.
> > >=20
> > > ... if=3D"debugmode" ...
> > >=20
> > > for backwards compatibility or
> > >=20
> > > ... if=3D"@call("available", "file", ${file}) =3D=3D true()" ...
> > >=20
> > > to indicate that the "available" task should be called with
> > > 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
> > > 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
> > > Phil :n)
> > >=20
> > > On Thu, 2004-07-22 at 11:47, Stefan Bodewig wrote:
> > >=20
> > > > On Thu, 22 Jul 2004, Jose Alberto Fernandez
> > > > <jalberto@cellectivity.com> wrote:
> > > >=20
> > > > > As per if/unless itself, I really would like to explore more=20
> > > > > what
> > > > > some people have suggested about having a richer language=20
> > > than just
> > > > > set/unset.
> > > >=20
> > > > PropertyHelper?
> > > >=20
> > > > IOW, I think we already have the infrastructure needed to
> > > do that in
> > > > Ant's core.
> > > >=20
> > > > Stefan
> > > >=20
> > > >=20
> > >=20
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For=20
> > > > additional commands, e-mail: dev-help@ant.apache.org
> > >=20
> > > --
> > > Phil Weighill-Smith <phil.weighill-smith@volantis.com>
> > > Volantis Systems
> > >=20
> >=20
> >=20
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>=20
> --=20
> Phil Weighill-Smith <phil.weighill-smith@volantis.com>
> Volantis Systems
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org