Do you mean maven modules? I.e. application dependencies?
Or do you mean split-points? I.e., the code is only downloaded and loaded when requested for the first time (after that it's stored locally depending on your browser and cache settings).
Ok. This is pretty advanced. We are doing this with our projects but it's not like you're thinking and I don't think it will work like you're thinking. Here's why:
Think of a normal Java application, say Swing. This is done quite easily if you have your main application scan a, say "plugin" folder, at launch time so that any plugin JARs get loaded on the classpath. Downloaded JARs would be placed in this directory and then simply relaunching the app (or dynamically loading the JAR via a dynamic classpath would/should work).
Unfortunately, GWT applications are NOT Java applications per se. Rather, there are two sides: the server-side which is Java only and that functions as one would expect a normal Java application to function. The second side is the client-side. Recall that there are two phases to the compilation process for GWT web applications. The first is the normal Java compile process. The second is the GWT compile process which builds Javascript versions of any relevant and required shared and client Java classes.
I do not think it is possible to JAR up the GWT compiled code and expect to be able to use it because how would the main application even know about it? It's Javascript, not Java.
What we do, however, and this is SIGNIFICANTLY more efficient, is have our child applications configured to build JAR files and have the parent application have dependencies on the children. The Java side works as you would normally expect but when the GWT compile phase kicks in, it GWT compiles ALL the relevant shared/client-side code from ALL the projects (parent and children) together. This means if you're using, say, a TextButton in multiple projects, the code is only included ONCE for ALL the projects to access.
What you would need to do is build in security so that someone who doesn't have permission (or has purchased) access to the Sale module to not be able to access or use it. We do this via Spring Security and Roles. If the user does not have the appropriate role, we do not even render the component. NB: THERE IS NO CLIENT-SIDE SECURITY and frankly, there cannot be. The entire application is either downloaded or accessible via split points, so the onus would be on you to ensure server-side code cannot be executed were someone to hack the client-side code.
Yes, the client-side code is obfuscated and compressed but security through obscurity is not security and the GWT-RPC URIs are not and cannot be obfuscated so someone with enough time and patience could find out what paths exist on your server. We mitigate this by using Spring Security on our servlet methods so that only requests from authenticated users with the right role can execute the method - a 403 Forbidden is returned for users who do not. The great thing about this is that this cannot be hacked (well, not easily) since it's all server-side code and the user's authentication is stored by Spring on the user's session in read-only form.
So, essentially, what you want can be done. Just not in the manner you've indicated above. I will say that it took me a while to get all this working correctly because there's a lot of moving parts and you want stuff to be reusable. Additionally, there's some URI name-spacing issues you will need to resolve if you want your child applications to have their own, independent URI namespace so they do not clash with each other or the parent app. I had to write a custom generator for RemoteService implementations to do this and not use GWT's built in generator.
Let me know if you have questions as you progress and I will try to help you as best I can. Again, there's a lot of work involved here but if you do it right, you'll have a VERY flexible platform on which to build a robust and pluggable web application.
Unanswered: Dynamical Module Load in Big GWT & GXT Projects
Reply With Quote