Hi Jonathan, I've messed with this challenge with varying levels of success.
The primary issue is if you're changing a few modules (say A, B, and C) and those modules have interdependencies (say C depends on A). If you go parallel, C is likely to resolve the old version of A. Not saying it can't be done, but to make things simpler the last build pipeline I did in this manner: 1) identify changed modules and build/unit test them in order (serially), 2) identify impacted non-container modules (jars, etc. that depend on changed modules, directly or indirectly) and process them fully parallel , 3) identify impacted container modules (war, ear, etc.) and process them in parallel. (not using subant, btw -- just "runtarget" from ant-contrib and overriding a few properties) However -- if you're still building to or from a standard disk (or SAN, or NAS) then you're more likely to get a much bigger benefit to moving over to SSD to RAM than you will from parallelizing individual modules builds - and much simpler too. I normally see commit builds in an I/O bound situation which slows them down. Try running your build from /dev/shm and see what kind of performance difference you get. HTH, ~Tim On Fri, Jul 8, 2011 at 1:40 PM, Jonathan Williams <spamhammer1...@gmail.com>wrote: > Hi, > > We currently use Ivy:buildlist + subant to build a large multi-module > project. As the project grows, the topic of parallelization has inevitably > come up as one of the ways we could speed up compiles. A search on this > topic has shown some interest in implementing this in the past, but nothing > recent or concrete as far as results go. Does anyone have a solution for > this, or are we SOL? > > -Jonathan >
