ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Mauri" <>
Subject RE: Opinions on a possible optimization enhancement to Ivy buildlist to support a form of incremental build
Date Thu, 25 Aug 2011 23:39:24 GMT

-----Original Message-----
From: Nicolas Lalevée [] 
Sent: Tuesday, August 23, 2011 5:32 AM
To: Ant Developers List
Subject: Re: Opinions on a possible optimization enhancement to Ivy buildlist to support a
form of incremental build

Le 18 août 2011 à 21:21, Richard Mauri a écrit :

> I would like to get a discussion started around an enhancement I am
> considering to contribute to ivy buildlist.
> I think it would be a valuable addition, and would like to hear from
> others before contributing a formal patch/contribution.
> The goal of this contribution is to support a form of incremental build
> where given a set of changed components the buildlist would return a
> short list of components that must be visited for rebuild.
> Consider a hierarchical component directory structure (the project) and
> a master build.xml with subdirectories containing ant/ivy components.
> Parent
> |
> |-A
> |-B
> |-C
> |-D
> |-E
> Consider a dependency relationship like (A depends on B etc.)
> A
> /\
> B C
> \ /
> D
> |
> E
> Today, ivy buildlist can be used by this parent build to ultimately
> determine the ordered build sequence (in this case starting from most
> independent).
> E D B C A 
> Now, given that the  toplevel build has available to it a set of
> components have been touched (Change-Set) , 
> I'd like to constrain the list returned by ivy buildlist so that only
> those components in the change set PLUS 
> the components that directly depend on the change set is returned (the
> rebuild-list).
> The reason the direct dependencies are included is to catch API contract
> violations that must be caught during the rebuild.
> Change-Set: {E,C}
> Rebuild-List: E D C A
> I assert that subsequent subant iteration over Rebuild-List would be
> more optimal than iterating over the entire project
> (imagine 100's of comps in the project).
> The enhancement to build list would be to add an attribute that
> represents the Change-Set and enhance the DFS DAG traversal reporting to
> return only the Change-Set and the components that depend directly on
> Change-set
> Thoughts?

I find it quite weird that transitive dependencies are not taken into account. In your example,
what if B was using some of E as by transitivity it's got into its libraries. B should be
recompiled then, no ?

If I understand correctly the problematic and if the transitivity is to be taken into account,
I think a simple modification to ivybuildlist would be needed : make it support several roots.
A such improvement would definitively makes sense.


Thanks for the response Nicolas

You're right, transitivity has to be accounted for.
The example of B calling an inherited method e1() defined on E, would demand that B be recompiled
when E.e1 signature changed like to e1(int i).

Regarding the support for several roots: I see now that there is support for multiple roots
or leaves.
I think I'm interested in the multiple leave feature of ivybuildlist. Given my leaves/known
changed modules {E,C}
return the modules that directly or indirectly! Depend on these leaves.

So no enhancement needed. Right!

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

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

View raw message