That is where we started, but thanks for the reminder to check it again -- things may have changed. (They didn't, but it doesn't hurt to look!)
During various JavaOne and GoogleIO presentations a few other methods have been identified to speed things up, but for the most part we have incorporated those ideas already as well. If I recall correctly, the folks at ZoHo are migrating to GWT from a set of JSPs, not unlike what we are up to; perhaps they have some tips. I can't imagine many other teams being in a similar situation with a large number of modules. Thanks, - Jim. On Feb 19, 6:43 am, DaveC <[email protected]> wrote: > The only thing I could suggest is outlined > herehttp://code.google.com/webtoolkit/doc/latest/FAQ_DebuggingAndCompilin... > (but you've probably already looked at this...) > > Sorry I can't be more help - it has got me thinking though, where I > work will probably run into the same problem in the (near) future. > > Cheers, > Dave > > On Feb 19, 12:47 am, JimmyJoe <[email protected]> wrote: > > > > > I appear to be in a rare situation with regard to GWT use: my team > > has dozens of independent GWT modules and our compile times are rising > > as we add more modules. > > > A couple years back the company I work for decided to switch to GWT > > for new product development. We have a SaaS portal that has dozens of > > legacy applications written in JSPs, so this was a big change for > > us. > > > Now that we do all new development in GWT, we are developing all new > > products as separate modules, each of which is hosted in its own JSP > > (to take advantage of all our legacy code there, punt on some > > development costs, etc.). They fit in with our existing code very > > well. > > > Long story short, we now find ourselves with upwards of 20 modules and > > climbing, and our complete build times are getting extraordinarily > > long. > > > Here's a little more info: > > > Many of our modules are built on a common framework which is its own > > module sans entrypoint. Often a module will consist of a single page > > of functionality distinct from other features in our product suite -- > > for instance setting org preferences, searching for emails, etc. Some > > of the modules could be combined, such as "administration" modules; my > > concern with that approach is that we're still using GWT 1.7 and don't > > have code splitting to keep our performance numbers good if we go that > > direction. > > > Regardless of that special case, however, we will eventually have > > dozens of large(-ish?), complex GWT modules that need to be regularly > > compile. Even with Ant's <parallel> and GWT's localWorkers we are > > already seeing significantly extended compile times. > > > Our current approach for single product development is to comment out > > all the modules that are not under development (Google's own best > > practice, as far as I have heard), and we are using development mode > > extensively, which obviously removes the need to compile the GWT code > > often. We also do no internationalization or localization. > > > What are your thoughts? Is there a good way to manage a large number > > of modules and keep compile times down? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
