Comment by m.zdila: @br: We can compile together the client code for all the current modules, but it would not be very OSGi conforming. For example, imagine that some client bought our product including only some of the modules. It would not be very clean to include client code for all the existing modules as one monolithic build. Even if we gave him only the client code for the bundles he bought, then if he would buy additional bundle(s) and dynamically install it to the running system, there would be no chance to add the additional client side part to the existing monolithic build. Simply, each server-side user bundle should have its client module counterpart so they can be dynamically added/removed without recompiling (all) the client.
Currently, as described in my first post, the shared workspace code gets duplicated. And exactly this is what makes traversing between modules slow - the JS code must be dowloaded every time (if not cached), parsed, and the workspace initialization code must be run. This way the monolithic build give us the opposite of the desired speed improvement. I admin that I don't know much about the optimization internals. Despite of that I dare to imagine that (in a near future) it would be possible the common workspace module to be separated from the view modules. The optimization can stay within the single module (build). The interface between workspace and view is governed by the Java interfaces (or maybe even the classes) and so the compiler can take it to the accound when optimizing. I personally would rather have this functionality even if the code would not be as much optimal as possible ;-). In any case, currently we can live just OK with our current solution. Good luck! For more information: http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
