ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Alternatives to Ant's XML Syntax
Date Tue, 29 Jun 2004 06:45:47 GMT
I'll try to summarize my view on some of the things that have been
said in this thread.  All I say are my personal views, other Ant
committers may have different opinions, of course 8-)

Use something other than XML
============================

So far no other syntax I've seen really looked more appealing to me,
but that's largely a matter of taste.  Ant should support alternative
syntaxes (does that word exist?) by allowing custom ProjectHelpers and
if there are any issues precluding that, we should know about and fix
it.

I certainly know James' article on it (a lot of discussion goes on in
blogs, doesn't it?), but his points are not really related to using
XML at all IMHO.

Should the core committers care?
================================

If one of the core committers really wants to use a different syntax,
he (sorry, Diane has gone, no women right now) should do so.  I for
one don't and thus I probably wouldn't spend time trying to write
support for a different syntax.

If anybody else wants to add support for it and faces obstacles inside
of Ant, that is a different issue and then I certainly would help with
adapting Ant.  Inside the of the confines of backwards compatibility,
that is.

More expressive build language
==============================

There certainly are build situations where Ant's core tasks aren't
enough and where you really want to do more procedural or scripty
stuff in Ant.  Some people (like Martin Fowler) prefer to write the
procedural parts in a scripting language like Python or Ruby and
others (like me) prefer to write them in Java inside of a new task.
YMMV.

If you follow Fowler's bliki entry you'll find a link to a blog entry
of Jon Tirsen who wrote this "Ruby using Ant tasks" thing.  The same
article was part of a larger TSS discussion and during this discussion
it turned out that one of the unmaintainable build files causing
problems had been turned into a maintainable chunk by a co-worker of
Jon - by writing a custom task.

Relax-NG or other snippets to validate tasks
============================================

I don't know enough about all the different syntax approaches for XML,
but I'm afraid that no language (XML schema, Relax-NG, whatever) is
rich enough to express what Ant tasks can do.

How would you deal with elements implementing DynamicConfigurator?
I.e. elements whose Java representation decides at runtime which
attributes or nested elements it is going to support.  Ant's CVS HEAD
contains an XMLFragment class that will accept everything as nested
elements - everything that is a well formed XML fragment, that is.

How would you deal with the new add(X) and addConfigured(X) methods?
<condition> now (Ant 1.6.0+) supports arbitrary named nested elements
as long as the element is represented by a class implementing the
Condition interface (or is adapted to it).  The task writer can't know
those elements and thus not say what their name will be, which
attributes or nested elements they support.

While some kind of validation would be nice, it will never be possible
to perform a complete static validation of Ant build files.

Still "schema or whatever" snippets would be useful for the cases
where static analysis works.  They'd also be useful for a wizard in a
GUI frontend, for example.  Some Ant committers have shown interest in
supporting something like this (related to the XDoclet driven
documentation of tasks), but it hasn't gained much momentum yet.

Stefan

-- 
http://stefanbodewig.blogger.de/

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


Mime
View raw message