technically the project consists of 4 separate apps, so 4 modules that
are compiled individually and it supports 4 locales. Is it unusual to
have such a large compile time?
GWT 2.3 introduces a new permutation for IE9. This can explain your
compile time. If you want to support IE9 "natively" you have to accept
that I guess...
Best,
Raphael
In the project I'm working on we have about 300k LOC and ~7000
classes. The GWT Compiler is invoked with the following arguments on
the build machine (this machine has 8 cores and 64gb of ram): -
Dgwt.localWorkers=8 -Xmx2048M -Xss1024M and there are 48 permutations
to compute. Do you guys have any idea what else we could tweak here?
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
In general, I don't think it is a good idea to have one build for
(many) different purposes.
For unit tests you don't need all browsers so pick one and stick with
it. In fact, for unit tests you don't need any browser. :-) Your unit
test build can and should be very fast. This should be the most
stripped down version you can think of. Mind you, it would be even
better if you broke up your app into separate modules so that all the
unit testing is done in the small, fast module builds.
The second build would be for integration testing. For your automated
integration testing you don't need more than one browser either.
(Unless, of course, you have a very advanced setup testing multiple
browsers.) Run this build once or twice a day at a specific time (say
lunch time and dinner time). (The specific time is so that people know
about it and can try to make sure their change is (or is not)
included.)
If the automated integration test build is successful then kick off
the full build for all browsers. This need only happen once a day or
even once a week. This build is then used for manual testing. It
should be auto deployed to some QA/test environment. Most (test/QA)
people don't like working with a moving target (for obvious reasons),
hence the "build once a week" suggestion. Then, if QA says this build
is good, promote it to production; no need for another build. I.e.
assuming you follow the best practice of not including your
environment configuration in the WAR.