May 19th, 2009

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:

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. So you might have a project structure that looks like this:





Your GWT module super-source tag would then use path=”hack”.
The package declaration in your emulated Java classes would then say “” (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, and will give you errors.

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





Your GWT module super-source tag would then use path=””.
The package declaration in your emulated Java classes would then say “”, 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.

  • Tyler Van Gorder

    Did you ever find a solution to the mismatch between the eclipse gwt tooling and the use of super-source? I ran into the same problem. I am wondering if you tell eclipse to exclude the “hack” package, if that will work correctly? By “exclude” I mean going to the project’s Java Build Path, on the “Source” tab selecting the source folder and adding an “Exclude Rule”


  • admin

    Sorry Tyler, I never did sort this out.

  • James Nelson

    Tyler, you can indeed use eclipse exclusion patterns like **/hack/** to hide your emulated source from eclipse. You can still open and view the source using the plain, non-source folder, and navigate to your hack/emul/super package as well.

    Another handy trick is to set up a symlink project external to your project. Have it declare dependency on the project it is from, plus link your emulated super-source by adding the hack/emul/folder itself as a source folder (or a real symlink if you want to get fancy on unix).

    This will give you a gwt-script view of the entire project, complete with java tooling. Although, you would be wise to include copies of the core gwt emulated classes as source roots as well, so you don’t accidentally reference methods which aren’t there.

    You can do this by checking out gwt source, then add the following source roots:

    This will give you a fully functional super-source environment in which you can actually make sure your syntax is fine without having to recompile. (Autocomplete support is nice as well. :)

    Oh, and a bonus tip: When you use an array, you don’t have to do bounds checking in super-sourced code!
    String[] arr = new String[0];
    arr[arr.length] = “push string”;

  • Ahmed Qasid

    I put my supersource folder in the resources folder (I am using maven) and every thing was fine. Eclipse does not compile files in the resources folder and gwt picks them up

This work is licensed under GPL - 2009 | Powered by Wordpress using the theme aav1