ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Scokart <>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Sat, 18 Feb 2012 10:02:28 GMT
For me, one feature for a 2,0 would be a different style of dependency
tree that would allow better parallel execution (on the same machine,
or why not on distributed machines).
I see the 'targets' being more declarative, becoming a state
transition saying : I need this resources in that state, I will use
this other resources (and I don't want the to change during my
execution, and I will produce this other resources in that other

The dependency tree would be an logical engine finding the shortest
path to go to the desired state, using parallel/distributed processing
when possible.

That's what I miss with existing build system : I want to go as
quickly as possible to a desired build state (from a current state).

Gilles Scokart

On 17 February 2012 20:07, Bruce Atherton <> wrote:
> 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
>> 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:

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

View raw message