On 19/04/2012, at 5:54 AM, Adam Heath wrote: > On 04/18/2012 12:46 PM, Jacques Le Roux wrote: >> From: "Adam Heath" <doo...@brainfood.com> >>> On 04/18/2012 12:28 PM, Jacopo Cappellato wrote: >>>> On Apr 18, 2012, at 7:20 PM, Adam Heath wrote: >>>> >>>>> ps: I am going to switch <if> in ant *back* to javascript, *away* >>>>> from >>>>> ant-contrib. The latter is significantly slower when using a system >>>>> installed ant. >>>> >>>> No please, don't do that. > > You didn't give a reason as to why I shouldn't switch back. If it's > because of things not working(at all), then list those problems. I've > already discovered some cases of embedded jar paths in the build.xml > files that are out-of-date(I can't do cd framework/base; ../../ant > tests-cobertura, but using the system-ant does work(once I fix the > broken paths).
Have you considered working with the ant project at all to fix the issue? The problem we have and I think we want to address is simply a case of way too much code in this project trying to do way too many things and being maintained by nowhere near enough people with the expertise to do so. We're attempting to take a good hard look at where we can pass the responsibility for maintaining that functionality off to more appropriate parties. Unless there is a very good reason for not contributing improvements back to ant then I can't see why it wouldn't more sense to do so. >>> I've pointed out a problem, and I have a solution. Don't just respond >>> saying don't do that, without a reason. That isn't enough to stop me. >>> >>> ant-contrib If-ant.js >>> (system-ant) >>> Apache Ant version 1.8.0 compiled on March 11 2010 >>> time ant clean 18.131s 8.291s >>> time ant build 44.072s 34.749s >>> time ant build 20.228s 10.559s >>> time ant clean 18.222s 8.490s >>> (local-ant) >>> Apache Ant(TM) version 1.8.3 compiled on February 26 2012 >>> time ./ant clean 3.575s 3.218s >>> time ./ant build 28.985s 28.909s >>> time ./ant build 5.486s 5.232s >>> time ./ant clean 3.876s 3.378s >>> >>> The first ant clean is run when the system is already cleaned. The >>> second ant build is also run when everything is already built. It's a >>> way to test what happens when nothing is done. >> >>> first ant clean >> ie with (system-ant)? > > The first 4 runs are with the system ant. The second 4 are with the > local ant. notice the './' on the second set. That's the clue. > >>> second ant build >> ie with (local-ant)? >> >> I don't see much diff with (local-ant). why not using the embedded ant? > > They are all slightly slower. And that's not noise, it was consistent > in my runs.