http://gwt-code-reviews.appspot.com/1518803/diff/1/dev/core/src/com/google/gwt/dev/CompileModule.java File dev/core/src/com/google/gwt/dev/CompileModule.java (right):
http://gwt-code-reviews.appspot.com/1518803/diff/1/dev/core/src/com/google/gwt/dev/CompileModule.java#newcode194 dev/core/src/com/google/gwt/dev/CompileModule.java:194: Map<String, Set<String>> unitsInArchives = new HashMap<String, Set<String>>(); On 2011/08/11 15:29:46, jbrosenberg wrote:
... What's the significance of units being written to the classpath?
Forgot to address this one. A module looks on the classpath to find .gwt.xml files, when it does, it also looks for a corrsponding .gwtar file. In a normal build, some earlier program put the .gwtar file there and it was there when dev mode or the compiler started, but when you are running CompileModule itself, you are creating these new files. In the normal ant build, the .gwtar files are directly output into the classpath, so that you can read them back when the next module is compiled. But some build environments write out the .gwtar file to a temporary spot, then when the entire CompileModule is done, it moves the .gwtar files onto the classpath for the next task in the build. CompileModule wasn't smart enough to handle that second case efficiently, and compiled each module as if there were no nested modules already compiled. http://gwt-code-reviews.appspot.com/1518803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
