ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Fri, 17 Feb 2012 19:07:58 GMT
It doesn't require a rewrite, but a rewrite could simplify integrating a 
usecase like this as well as integrating other features that we already 
have into it and making them simpler and unified inthe code. I agree the 
usecase is an excellent one which could simplify the lives of exactly 
the type of users I am talking about.

It sounds like you are suggesting that the dependency tree be extensible 
and modifiable, perhaps manipulable, within targets as well so long as 
that part of the tree hasn't run yet. In a sense that is what macros do 
because they allow you to swap in some static block of tasks to replace 
a single task. There is also the feature from EasyAnt for changing 
target dependencies. But what I'm hearing is that you want more 
flexibility than that.

Something to walk the existing dependency tree, perhaps, with 
conditional behaviors to modify the metadata on existing element such as 
dependencies and if/unless, replacing the element with another or a 
subtree (perhaps itself dynamically walked and created), adding 
branches, perhaps deleting elements or subtrees. Kind of like what we 
can do with a tree of files and directories already. Does that sound 
like what the design you'd like to see would have?

And perhaps it could encompass providing both the macro and target 
dependency changes to the tree as well, along with any other code we 
have that alters the dependency tree. I'm not sure which of the various 
ways to call back into Ant do this. I'm sure there are other examples in 
the codebase.

I'm not familiar enough with this part of the code any more to know 
whether there is already a single elegant solution in Ant 1 that all the 
code which modifies the dependency tree shares, but given our BC 
requirements I doubt it.

One example of a FileSystemProvider that Java 7 suggests in its API docs 
is a "memory" file system, one identified by the URL "memory://". 
Perhaps our dependency tree could be a kind of file system, then we 
could reuse vast swathes of code we already have, both in the standard 
class libraries and in Ant itself. Just an idea off the top of my head.

On 2/17/2012 5:53 AM, Dominique Devienne wrote:
> 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:

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

View raw message