MODELLING AND SIMULATION, WEB ENGINEERING, USER INTERFACES
May 20th, 2009

Convergence 1

Warning: Extremely Boring, Project-Specific Post

I worked really hard today, and I have lots to report. I started at 6:30am and worked straight through on GSoC until about 7:30pm. I also spent some time investigating alternate tooling, and I’ll talk a bit about this in another post.

So, to recap, we have this stack: Demos/GEF/Draw2d/SWT/JRE. The goal of this week is to get Draw2d to compile under GWT. After that, I’ll have to try to get it to run, but for now, I’m just concerned with getting it to compile. This, of course, means figuring out what Draw2d’s dependencies are in SWT and the JRE, and where they are not satisfied, writing out stub code and small TODO comments. Also, I will atempt, where possible, to reuse the existing, non-functional code from the previous project that used GWT to compile SWT to js.

To summarize my experiences of today: JRE == SUCCESS, SWT == FAIL.

First some background: GWT already provides some JRE emulation, but it is not sufficient to compile the SWT codebase. To get SWT to compile, one must at least implement certain stub interfaces that GWT does not provide. There are additional issues, such as reflection, that may be more serious, and I’ll talk about those in a later post. The extension to the GWT emulation classes live in the project org.eclipse.swt.e4.jcl. Left over from the previous project were three GWT modules which I was never able to compile. Additionally, it was unclear to me how these modules were supposed to compile, as they used the GWT module “source” tag, rather than the “super-source” tag, which, according to all of the documentation I have read, is what one is supposed to use when implementing JRE classes.

Today, I successfully compiled the previous project’s JCL classes. In order to accomplish this, I applied Technique 1 from my previous post, which is to say, I added a prefix (“e4″) to the JCL packages, where before there was no prefix, and I used <super-source path=”e4″/> in my GWT modules. I had to futz a bit to discover in which order I should import the modules, but after that, they compiled without complaint, w00t

//TODO: insert complete project structure here

Note that, since yesterday, I have been developing this prototype outside of the Eclipse environment. My toolset has consisted of GNU Screen, Vim, a Vim plugin called VimExplorer, and Ant. This has allowed me to ignore all of the IDE-specific confusion that I have so far encountered. My next post will be about my experiences using some of these tools.

I was feeling very optimistic after succeded in getting JCL to compile, so I set it as my goal to get the necessary SWT libraries to compile as well. Unfortunately, I failed in this task, because, I believe, I took the wrong approach. The approach I took was to attempt to reuse directly the SWT emulation classes left over from the previous project, just as I reused the previous project’s JCL classes. Unfortunately, these SWT emulation classes had many missing dependencies. My strategy was to just keep hacking on it (adding in missing classes, stub methods, etc.), until the thing worked. I spent most of the afternoon working on this, probably about 4 hours. Ultimately, I ended up pulling in most of the code in “org.eclipse.swt/Eclipse SWT/common”. I didn’t get to the end of the dependency chain, but I think I got far enough along to recognize a trend that I wasn’t happy with, namely, pulling in dependencies that in turn rely on other dependencies, etc. It should be a major priority to limit dependencies, because the more deps I cut out, the less complex my project will be. Given that this project is still at the prototyping stage, reducing complexity is of critical importance.

Note that I also tried compiling “org.eclipse.swt/Eclipse SWT/common”, but this pulled in some native code which GWT was unhappy with. So, I really do need to be selective.

The alternative to today’s approach is to start at the top of the stack (work top-down) and discover what the dependencies are for the Draw2d demos; then, find out what the dependencies are for Draw2d; then, very carefully, attempt to pull in those deps from org.eclipse.swt, or stub them out. I intend to use Doxygen to figure out the complete dependency chain. This will be tomorrow’s work.

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:

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.

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