ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Fri, 17 Feb 2012 13:53:33 GMT
2012/2/17 Bruce Atherton <>:
> A lot of companies have their own, internally written build file generators
> just so their build systems are consistent and exactly what they want. Our
> Related Projects and External Tools page has some of these that were made
> public, I suspect.
> Surely there is a better way than requiring users of Ant to write generators
> to deal with the complexity and keep it customized.

At one point I did write a build(s) (XSLT-based) generator
specifically for a large and hairy project. Later I rewrote the whole
thing with macrodefs. But my point is that I don't view build
generators as bad, in fact it often helps IMHO to have a declarative
custom DSL (in XML in my case, so read "DSL" with a grain of salt)
that's used as the input for generating Ant build fragments, and have
those fragments be able to "insert" them into the target graph. I've
also long felt Ant needed generalized if/unless/os (and my own
extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
UnknownElement if you prefer), just read the recent "add if/unless to
<javac>'s <compilerarg>" thread. <macrodef> is nice, but you can't use
it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
those things you can often do more easily with a generator, but that's
often cumbersome, doesn't play well with IDEs, etc... I guess I'm
saying I've often wished for generator-like features as a built-in
part of Ant. Do you see what I'm saying? Ant now does late
"conversion" from UnkownElement to actual configuration of the Java
code it maps to, and a way to influence/transform that almost AST-like
graph would make Ant more powerful and flexible, perhaps at the
expense of creating "dialects" unreadable to someone not familiar with
them. Given Ant's XML roots, perhaps a tighter built-in integration
with XSLT to dynamically "rewrite" the build at runtime/buildtime
would be one way to achieve what I envision (notwithstanding the talks
of non-XML front-ends of course).

Stepping of my soapbox now :)  What I'm saying has nothing to do with
Java7, nor necessarily require a rewrite either. --DD

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

View raw message