ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: ANT 1.7 features suggestion
Date Wed, 05 May 2004 17:22:27 GMT
> From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]
> > From: Dominique Devienne [mailto:DDevienne@lgc.com]
> > > From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]
> > >
> > > -100 :-\
> > >
> > > IMHO, if/unless in targets are one of the worst features we have in
> > > the ANT language.
> >
> > I'm completely at the other end of the spectrum! I think
> > if/unless, and extension of these that I coded up in my
> > custom tasks/types, make the build a lot easier to read, and
> > are absolutely essential to Java development with a lot of
> > native code underneath like here.
> 
> But we already have all this in our ANT conditions. So why do we want to
> redefine them again with a new syntax? How do you add new conditions?
> Because the need for new conditions to check does not end today.

Along this line of thought, XSLT would not have used XPath expressions, but
a bunch of nested XML tags to specify what a simple string can express. I've
just read that last night from Michael Kay's XSLT book (very good so far by
the way). Thank god the hyper verbose pure XML syntax was ditched and XPath
parses a string to know what it should do.

This is exactly why I prefer 100 times inline conditional attributes, and
why I'd like to have my current custom conditional attributes on all Ant
types/tasks. I'd actually love to be able to have an XPath boolean predicate
that could have access to the Ant Object Model (hierarchy of task/types) and
Context (to access properties and references).

These mini-languages are just plain easier to read and write, and a long
terser than the equivalent XML you can invent. This is why XSLT has XPath,
and why Relax-NG has the compact syntax.

I actually like having to deal with XML for Ant build file, but for
condition XPath or any other simpler is tons better is a lot of cases, even
though I want to retain <condition> for the rare cases I need so heavy duty
logic.

The properties I test are only static properties, set in properties file,
not dynamically computed, so I don't have any spaghetti code. --DD

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


Mime
View raw message