Summary of Some of the Pecularities Involving GWT Eclipse Tooling and Super-Source

I've been having some difficulties figuring out how to use the super-source tag for GWT's module files. See the following forum posts for more background on this:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/933d511f524cc355/6c9216fd943e3f47?lnk=gst&q=otakuj462#6c9216fd943e3f47
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/776660639069c8e9/98bc3c99c7a2848f?lnk=gst&q=otakuj462#98bc3c99c7a2848f

In short, there is a kind of impedance mismatch between the functionality that GWT provides the functionality that GWT's Eclipse tooling provides, at least with respect to super-source. Here's my understanding of how all of this breaks down:

1. You can use a package structure in which the native packages you would like to emulate (e.g. java.*) are prefixed by some other package (e.g. hack.java.io). So you might have a project structure that looks like this:

testsuper/
        super/
                test/
                    TestSuper.gwt.xml
                test.hack.java.io/
                     OutputStream.java 

Your GWT module super-source tag would then use path="hack".
The package declaration in your emulated Java classes would then say "java.io" (no hack prefix!).

The Pros: This works great in both GWT hosted mode and compiled mode.
The Cons: The Eclipse IDE will think that something is wrong with your package declaration (it thinks it should be hack.java.io), and will give you errors.

2. You can use a package structure which does not use prefixed packages. So, you have something like:

testsuper/
        super/
                test/
                    TestSuper.gwt.xml
                test.java.io/
                     OutputStream.java 

Your GWT module super-source tag would then use path="".
The package declaration in your emulated Java classes would then say "java.io", as per normal.

You then have two further possibilities:

2.a. Put super/ on the Eclipse build path.

The Pros: GWT Compilation mode works, and the Eclipse IDE doesn't throw errors regarding packaging.
The Cons: GWT Hosted mode fails, ostensibly because it's using the incorrect Java classes. In fact, I'm not really sure why GWT Hosted mode fails with this setup, but it surely does.

2.b. Do not put super/ on the Eclipse build path.

The Pros: GWT Hosted mode works (although you must set the runtime classpath to point to whatever dependencies TestSuper has; you set this as an Eclipse run configuration), and the Eclipse IDE doesn't throw errors.
The Cons: GWT Compiled mode fails for the Eclipse GWT tooling, if you have projects that import this project, because the super/ folder is not on the Eclipse build path. If you were using Ant, this would not be a problem, because you can simply set the build-time classpath, but it does not seem to be possible to do this yet with the Eclipse tooling. Also, because super/ is not on the build path, you don't get all of the advantages of the Java tooling that you would normally get from Eclipse.
Workaround: Use ant within Eclipse to Compile, and use regular GWT for Hosted mode.


It's important to point out that all of these issues are related to the GWT Eclipse tooling, not GWT itself. Nevertheless, for my project, I am strongly dependent on Eclipse, so it is necessary for me to find the best way to resolve these issues. I'm not 100% certain about this, but at the moment, I feel like my best option is to go with option 2.b., so to stay in Eclipse, but move all of the build logic to Ant.