https://issues.apache.org/bugzilla/show_bug.cgi?id=45612
--- Comment #4 from Dominique Devienne <[EMAIL PROTECTED]> 2008-08-19 06:51:51 PST --- Well first, maybe it's the heavy use of <antcall> that's the performance problem! (had to put that one in ;-) OK, the use case you describe makes sense, although I'm not sure your approach is a pragmatic one. From my experience with large, multi-sub-project builds, restarting the build does indeed take a little time, but a well design build that does nothing when nothing needs doing quickly gets up to the end. My largest build ever with close to 100 different sub-builds of native C/C++/Fortran code took 30sec to recurse in every lib and exe and jar when everything was up-to-date. So the complex feature you are suggesting wouldn't buy you much, since once the build is designed, it rarely fails in the middle for nothing. Add validation targets to your subbuilds, and recurse on those in a first pass to find all potential issue quickly, then do the build per se on a second pass. To come back to your idea, you describe a "resumable" mode for Ant. The way I see it, the user would explicitly request Ant be in the "resumable" mode, and if something fails, you'd do "ant -resume" to restart it from the failure point. But that would imply tracking which targets ran so far, which one failed, both in which nested builds, etc... Plus what the properties where, and worse, what the reference datatypes were, which implies serializing the latter. So it's very difficult to code up. Specifying from which target to resume explicitly would be very brittle for the same property/reference issue. There's simply not enough bang for the buck here IMHO. --DD -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
