rather than using
svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/ trunk
you will want to checkout:
svn checkout http://google-web-toolkit.googlecode.com/svn/changes/jat/oophm-trunk-r2791/
Next, you'll need to add lib/sun/swing-worker-1.1.jar to tools/
john indicated that there was a commit message somewhere that
explained where to find this file (it isn't in tools yet), but I
failed to find it, so a quick google turned up this link:
Now, simply typing ant should kick off the build process, which
includes the build of the Webkit and FireFox plugins.
You might have to set some environment vars to get tools to resolve.
The plugins will be written to the build/staging/gwt-xxx-0.0.0/plugins
directory, you'll need to install the plugin into whichever browser
you intend to use for OOPHM debugging. For reference, the Webkit
plugin seems to work the best at this point.
Now, pick a project that you want to debug using OOPHM, and change the
gwt-user.jar and gwt-dev-xxx.jar references to point to the ones in
the gwt oophm build. NOTE: the new dev jar is simply gwt-dev.jar it is
no longer platform dependent.
next, fire up a shell! you'll get a new swing window saying that it is
trying to launch firefox with a particular url. At this point the
shell is mistaken, it isn't trying any such thing. start up your
chosen browser (with the oophm plugin installed) and point it to the
url stated in the shell window. you should now be connected.
I have noticed the following after using OOPHM for a while:
1) OOPHM is becoming useable, but it is still alpha!
2) RPC is a bit broken in the firefox plugin. (any attempt to send an
rpc throws a ClassCastException. this is a known problem, and should
be fixed soon)
3) The webkit plugin appears to mostly work on leopard (seems to crash
out in tiger), but some long running tasks occasionally crash the
4) Connecting to a OOPHM shell from a remote machine is painfully slow
at this point, but it is possible. (think debugging your app from
windows, and linux without having to port your OS X dev environment).
5) the default linker template doesn't really allow OOPHM to support -
noserver yet, but it is possible to use the shell linker template to
get oophm working with -noserver (this does break web mode though)
6) the xxxCreator scripts still reference the platform specific gwt-
dev-xxx.jar file, so any output scripts would have to be modified
before they work properly.
7) The IE plugin doesn't exist as such yet, but it is being worked on.
Over all, OOPHM seems to be coming along quite nicely, and is pretty
usable with Webkit on leopard right now.
The plugin/shell communication could use some optimization as it
appears to be a bottle neck at this point, but debugging locally works
at a usable pace (albeit quite a bit slower than web mode)
For the brave souls out there that have been waiting for OOPHM, build
it and see what interesting ways you can find to break it. Remember
this is still alpha code, so treat it as such (you know ... don't work
directly with your only copy of the project you've been building up
for the last 2 years).
On Jun 27, 2008, at 9:22 AM, jay wrote:
> I've searched this (and other groups) for more information on the
> OOPHM work. I've found this thread to be helpful:
> I also found what appears to be a branch where work is actually going
> What I cannot find, however, is any hints or tips on how to go about
> building and running with OOPHM.
> Any pointers would be greatly appreciated.
So, now you can debug from Safari, and IE. Firefox works if you don't
So to revisit my previous list of noticeable issues (see below):
1) yup, still alpha but getting better.
2) Firefox plugin is still grumpy.
3) Webkit plugin works great on Tiger and Leopard (I had to recompile
the plugin for tiger using the 10.4 setting in XCode)
4) OOPHM seems to be much faster when the browser is on a different
machine (on the same network) than the hosted shell, and at this
moment, it appears that IE is actually the fastest (who'd a thunk it)
7) IE plugin was committed today!
> -noserver yet, but it is possible to use the shell linker template
Way to go BobV!!!
Hell of a first shot at windows / COM programming.