Sorry for the super slow reply – I didn’t see this comment!

Honestly, I think I would lean toward the two module solution as well…just because the code seems so distinct/separate…there’s no real navigation between the two modules…and like you said, you wouldn’t have to bother with code splitting. That’s just my 2 cents though!

Overview:
You have two main module that you want to put behind a login and you want to have full GWT-Control over your login page. I have created a Login module which loads and will fire a quick rpc to check for an existing session (if so redirect). It will show a form to either login or register

The web.xml defines two servlets for the two main modules and a servlet for the login module. The two main module servlets are very basic. All they do is check for an existing user (if yes: return an html page which poitns to ModuleX.nocache.js, Otherwise, return an html page the loads the login.nochache.js)

The default welcome file will just load login.

Just wanted to post this as a reference to whoever stumbles across it..

Check out the web.xml and the servlets and login (entry point)

Demo:
http://gwt-advanced-login.appspot.com/

Code:
https://github.com/ashtonthomas/GwtAdvancedLogin

There’s an architectural issue that is troubling me, which I’ll explain in a moment; but first I need to present some background information.

I have a web app that is fronted by a set of ‘landing’ pages, which have marketing gumph and a nice big green Sign Up button. Because I want search engines to fully index the marketing goodness, I want the landing pages to be delivered to the browser as HTML (as opposed to a ball of untrawlable GWT JavaScript). So far so good; the landing pages can be implemented as HTML files served up by Tomcat.

Now I want to add a login panel to the masthead of my landing pages. Returning users can enter their email address and password into that panel, and be given access to the application proper. OK, so that’s just a simple HTML form, and a servlet/JSP on the server-side to handle the authentication, as per Google’s article, Using a Dynamic Host Page for Authentication and Initialization.

Here’s where it gets tricky. I want to give the login panel some smarts; for example: labels that are rendered inside the fields, and fade when you type over them; a cool animated wait icon; and nifty handling of error conditions. I guess I could use JQuery for that, but hey, I already have my hammer (GWT), and this login panel looks a lot like a nail.

It seems to me that I have two architectural options:

TWO MODULES: one module for the login panel, and one for the application proper. The login module is really small and attaches itself to the masthead of my landing page(s). Upon successful login, the login panel uses Window.Location.assign() or whatever to flip to the HTML host page that embeds the main application.

ONE MODULE: the module cleverly detects whether it is hosted a landing page or the main application host page, perhaps by looking for the DOM element that represents the container of the login panel. If it’s on a landing page, it inserts itself into the appropriate place, and activates just the code that it needs to perform the login, leaving the bulk of the application behind a split point. If it’s on the main application host page, then it attaches itself to the body of the document, and lights up the main application code.

I’m drawn to the two-module option because code splitting is fiddly and time-consuming, but having read your article, I’m no longer sure. I’d be grateful for your thoughts on the matter.

The “admin” vs. “normal-mode” module, I suspect, is the most common scenario, and actually that might have been a better example in the post. A separate module and EntryPoint is probably always warranted – the two “sections”, in this case, are really two separate apps (admin users only want to download admin code, there’s probably not much navigation between sections, no need to share state, etc.).

Developing an app for different clients can be extremely tricky, since as you said they can end up being pretty different. That’s a whole other post!

My experience:

I use a similar solution as Jim in that I only compile for one variation and for one module when I need. My compile times are only 3-5 minutes now so it’s not terrible. (I work 24/7 so sometimes I let it do a clean complete compile just for a break)

* My comments below are bias to my application and will probably taint the objective nature of Ben’s post *

However, when using code splitting you may want to compile soyc reports to understand what’s going on under the hood. In this case, compile time shoots up again

As far as organizing modules, I agree you will always have that “common” aspect and the balance between components built on top of the common aspects depends on all factors. You mentioned business units as separate components and another could be device. GWT makes it very easy to compile for different user agents.

However, I think that if you make a mobile version of your app then it probably needs to be a separate module if you are really going to make it worth anything. This is very tricky because you should have “common” areas all over the place. But the reason for building a mobile or tablet app would be so users could interact with it in a different way and the app could interact with the user in a different way. It should be (and by should I mean in my case the my app needs to function significantly different on other devices – different kinds of users are using it for different reasons) a different app with different application logic and flow (well different enough to where the pros of organizing into different modules may actually outweigh the cons).

I also use a different module to separate Admin functions from normal functions. Here there is a lot of overlap and I would like to have it as one module. However, I am building a user facing application and don’t want the Admin app logic (however ever obfuscated it may be – or what size) downloading with ever normal user. I briefly tried using code splitting to solve this problem but it just makes things too complicated and then I would have to authorize a client to download admin code and other problems arise. So that situation isn’t perfect

It depends. So that was my experience

Unfortunately, we’re using Maven…which limits some of our flexibility in building…so our approach is definitely less elegant than yours or Stephen’s.

Thanks for commenting!

Stephen’s strategy is a little more straightforward, but what we have done to help developers compile only those modules they are interested in is create text file which lists a GWT module on each line. This file is read in by an Ant script which ignores modules commented out with a hash — this makes it very easy to tune which modules are compiled.

To speed continuous builds, we have created copies of each module’s gwt.xml file which compiles each module for a single browser. These versions are only used when we set a build flag; this enables us, along with use of the –draftCompile flag and PRETTY formatting, to see build times of half of what they are when we are not using them. For getting fast confirmation that the build is not broken, this has been fantastic.

There are other tricks, which I have outlined here, but your article definitely covers this topic in much more depth.

Thanks for the writeup!

Developers run local compiles using AppCustom, the production builds are built from App.
Developers disable/adjust the config depending on what they are working on.

The AppCustom.gwt.xml isn’t committed to source control – so there is no danger of developers inadvertantly checking in their custom version and screwing up other developers or the production build.

This works well for us, especially as different developers work on different platforms and in different languages.

We use option (4) btw, however our applications are used internally by businesses, so having a single largish download (over 1Mb unzipped) per app isn’t an issue.