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 Tue, 21 Feb 2012 20:22:04 GMT
It sounds like you are both are on a similar wavelength. Let me see if I 

A new style of build (while maintaining the old style, of course) would 
be to declare some combination of resources to have similar states and 
transitions between states. So something like this (just as an example 
of a made-up syntax):

<state name="no-java-src" newstate="curr-src-present" 
<transition target="checkout-java-src" />
<state name="out-of-date" newstate="curr-src-present" 
<transition target="update-java-src" />
<state name="curr-src-present" newstate="compiled-java-src">
<transition target="compile-java-src" />
<state name="curr-src-present" newstate="no-java-src">
<transition target="remove-java-src" />

<path="src/main/org/apache/tools/**/*.java" />
<statechange from="no-java-src" to="curr-src-present" />
<statechange from="out-of-date" to="curr-src-present" />
<statechange from="curr-src-present" to="compiled-java-src" />
<statechange from="curr-src-present" to="no-java-src" />

and so on. The statechanges here are single steps from state to state, 
but presumably the from and to statechanges could be many steps away and 
Ant would find the best (for some value of best - fewest nodes, least 
cost?) DAG from one to the other.

Then to run the build you identify some combination of resources and 
states you want to end up in gathered together in another target or 
something similar. Is that the idea?

On 2/19/2012 1:26 PM, Dominique Devienne wrote:
> On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart<>  wrote:
>> 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).
> Agreed. I was in fact thinking of this one as well when I wrote my
> "integrated build generator/manipulator".
>> 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
>> state.
> Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
> you know the graph of actions to transition all input files/resources
> and come up with the optimum way to achieve the stated goals given the
> hardware resources (single cpu computer, multi-core computer, grid of
> computers). That's basically Makefile territory in a way, and similar
> to what Peter's<outofdate>  does as well. Right now Ant's targets
> typically deal with "macro" dependencies (build all .class file before
> building all .jar ones), and not "micro" dependencies at the file
> level, so the opportunities to do stuff in parallel are lessened IMHO.
> One reason Ant doesn't care much about this kind of parallelism is
> that Javac is fast-enough and cannot be distributed really, and it's
> the compilation of native languages like C++ that benefit most from
> those, and that's not Ant's territory in fact.
>> 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).
> Have you read the 4 part series about how Google does its builds?
> Below's a link to part#4. --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message