Ant build needs some love with respect to spurious rebuilds

[GoogleCodeExporter]

Sometimes, when we build/rebuild, stuff gets recompiled that doesn't need to 
be.  This ultimately cascades down to rebuilding the client, which is hugely 
expensive.  Not sure where the problem is, maybe around dto generation?

Original issue reported on code.google.com by dragonsinth on 4 Jul 2012 at 4:57

[GoogleCodeExporter]

I checked that a zero-change rebuild does not dirty itself, and a DTO 
regeneration "should" trigger a rebuild (in that the generated client code 
changed).  I'll watch for it, but if you happen to notice a too-large rebuild 
and can tell me what you edited, I can chase down what over-triggered what from 
there.

Original comment by freeland...@gmail.com on 4 Jul 2012 at 10:38

[GoogleCodeExporter]

Will keep an eye out.  We thought part of it might be having Eclipse open
doing stuff and outputing into the same folders as everyone else.

Is bin/classes both an input and output for any rules?

Original comment by dragonsinth on 4 Jul 2012 at 10:50

[GoogleCodeExporter]

No, bin/classes is pure output in any build environment.  But I can imagine 
some of the <outofdate> tags being a bit over-expansive in their <sourcefile> 
elements, which is the easy explanation, or perhaps getting some unexpectedly 
easily dirtied <targetfile>... more oddly, bin/classes is shared by ant and 
Eclipse, as is bin/gen (or bin/test/gen); I don't think Eclipse knows how to 
generate the source, so that has to come from ant, and then be found (and 
likely recompiled) by Eclipse; if Eclipse recompiled the bin/classes of 
generated source, that would appear <outofdate>.  Once, unless Eclipse 
re-recompiled them, etc.

Original comment by srthomas...@gmail.com on 5 Jul 2012 at 11:01

[GoogleCodeExporter]

Ah, that could be.  The Ant build would spit out class files pretty instantly 
after generation; Eclipse would probably lag behind.

But my question about bin/classes being in/out is really about the fact that 
successive build steps depend on outputs of *previous* build steps, yet output 
into the same location.  Take, for example:

http://code.google.com/p/collide/source/browse/java/com/google/collide/server/fi
letree/build.xml

You'll notice ${dirs.bin} is both a classpath element and the output folder; 
that's because it depends on already-compiled classes from the "shared" package.

In GWT we got around this by having each build different build produce its own 
jar.

Original comment by dragonsinth on 6 Jul 2012 at 4:59