Hey.
In which state is gwt 2.0 support in vaadin nightlies and eclipse-vaadin-plugin? I’m tempted in testing out the built in OOPHM in GWT2, but I just want to know if it is too early, are all tools needed already available and are there some gotchas that I should know about?
Update to the latest experimental plugin and you should be ready to go. The Eclipse plugin has been updated to understand GWT 2.0 so create a project, select a 6.3 nightly, create a widget or two and create a debug configuration from the preferences pages. Then just add a breakpoint and start the “GWT development mode for ”. Of course you should be aware that neither 6.3 or GWT 2.0 has been very thoroughly tested so far 
You might need to upgrade your browser plugin to the official GWT version. To do that go to
http://gwt.google.com/missing-plugin/MissingPlugin.html
. Be sure to uninstall the old plugin first (at least for Firefox) or it won’t work properly. (The official GWT 2.0 plugin probably does not work with the 6.2 OOPHM GWT).
Remember that the parameter that used to be gwt.hosted is now gwt.codesvr so add “?gwt.codesvr=127.0.0.1:9997” to your url.
I am already configured for GWT 2.0 in my Eclipse.
I have run the tutorial for vaadin and it looks promising, though it uses gwt 1.7 I believe. I didn’t note any problems, but then I never did a build and release to my regular Tomcat area. Is there still a GWT compile step necessary to do a build for release so I can run it outside of Eclipse?
How/where do I go to get the “latest experimental plugin”? I presume you are talking about the vaadin eclipse plugin. I would like to take the tutorial project and update it to the vaadin 6.3 so I can see how it works with GWT 2.0.
Thanks.
To get the experimental plugin, simply use http://vaadin.com/eclipse/experimental as your Eclipse update site.
What about Netbeans?
Any news?
I saw that link, but it gave an error in my web browser unlike http://vaadin.com/eclipse, so I hadn’t tried it in Eclipse software updates. Now that installed fine without any errors. Thank you much!
For the project properties, undler Google Web Toolkit, it shows GWT 2.0.0 from my previous install when doing direct GWT 2.0 programming. I have not checked the “Use Google Web Toolkit” option though since I’m not really doing it, and when I do check it, it seems to make no difference (cannot start as Web Application as it complains about “Could not find any host pages”).
The Java Build Path Libraries shows VAADIN_DOWNLOAD/gwt-dev/2.0.0/gwt-dev.jar and gwt-user.jar, as well as GWT SDK [GWT - 2.0.0]
, and it’s using the vaadin-6.3.0-nightly-20100113-c10705.jar file, I think it has the right VAADIN code for GWT 2.
But now how do I run it with the external browser+plugin (using FF 3.5 which already has the GWT 2 plugin installed)?
Is there a gwt.xml file to be used (module file) if I enable Google Web Toolkit under the properties (along with hosted mode page)
I tried using the URL doing a regular start (that also starts the Eclipse embedded browser) with http://localhost/vaadingwt20/?gwt.codesvr=192.168.1.9:9997, but that gets an error: Plugin failed to connect to hosted mode server at…
I am obviously overlooking something…
You do not need to enable GWT in the Google plugin.
For GWT 2.0 testing, you should be running two server processes in parallel: your normal application server (which seems to be running) and the GWT development mode server that the browser plugin connects to.
If the latter is not running, go to Project Properties → Vaadin, click the button to create a hosted mode configuration and run that launch in the debugger. When the project is using Vaadin 6.3, the generated launch will use the GWT 2.0 development mode rather than the old hosted mode.
The hosted mode process could also act as your application server with some command line argument changes (using an embedded Jetty) - that is how the Google plugin runs your application by default if I remember correctly. However, that would make you run your server side code in different environments when debugging client side code and when not.
If the GWT development server is running, make sure you are using a current version of the browser plugin and check your network and firewall settings etc.
Thanks, Henri. I am getting closer, yet not quite there.
I clicked the “Create Hosted Mode Launch” button in the Vaadin plugin, and it created a file GWT development mode for vaadingwt20.launch.
When I run it, it brings up the Development Mode tab with nothing in the “Startup URL” area.
Then I run in debug the project (vaadingwt20) using the Tomcat Server method (previously with GWT it just ran jetty as you mentioned), it seems to start up fine, and I see the embedded browser version startup and it looks normal, using the URL http://localhost/vaadingwt20/
I found that I run FF and use the URL http://localhost/vaadingwt20/?debug this also works and shows the page and allows me to debug in Eclipse, but it has a special “Debug Window” that appears in the lower right corner. This actually seems to be entirely functional for me – sometimes having to click “Restart App” button to get the debug breakpoints working.
It makes me wonder if I even care about the GWT debugging feature if I can run in FF and still reach breakpoints in Eclipse with the ?debug option. It seems like that’s why I wanted the GWT 2 debugger because I wanted to test in FF with Firebug, but still be able to use breakpoints in the Java code.
Then I tried FF URL http://localhost/vaadingwt20/?gwt.codesvr=192.168.1.9:9997 (the gwt.codesvr part comes from the param added when I run my pure GWT 2 project). I noted that a (FF) tab appears in the GWT Development Mode window, and it shows:
00:00:00.001 [INFO]
Loading module com.example.vaadingwt20.Vaadingwt20Widgetset
but then has an exception:
00:00:00.050 [ERROR]
Failed to load module ‘com.example.vaadingwt20.Vaadingwt20Widgetset’ from user agent ‘Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7’ at DavidHP2009.home:53947
java.lang.NoSuchFieldError: reportUnusedDeclaredThrownExceptionIncludeDocCommentReference at com.google.gwt.dev.javac.JdtCompiler.getCompilerOptions(JdtCompiler.java:309) at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.(JdtCompiler.java:147) at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:465) at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:141) at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:279) at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:181) at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:280) at com.google.gwt.dev.DevModeBase$UiBrowserWidgetHostImpl.createModuleSpaceHost(DevModeBase.java:97) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:180) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:380) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:222) at java.lang.Thread.run(Unknown Source)
I made no change to the generated com/example/vaadingwt20/Vaadingwt20Widgetset.gwt.xml file (not really even sure when/how it was created) since I was just running the tutorial code that I built step-by-step and seems to otherwise work fine. It shows:
[font=Courier New]
<?xml version="1.0" encoding="UTF-8"?> [/font]I do see the WebContent/VAADIN folder, with with my VAADIN/themes/contracts folder that was create during the tutorial work.
There’s also VAADIN/widgetsets folders com.example.vaadingwt20.Vaadingwt20Widgetset and com.example.vaadingwt20.Vaadingwt20Widgetset-aux that appear to be built during the “Compile widgetset” phase that shows no errors:
Compiling widgetset com.example.vaadingwt20.Vaadingwt20Widgetset
Widgetset compilation completed
What might I still be missing in my setup?
Thanks for your help.
The ?debug option is just a Vaadin option for displaying the debug window/debug information. It does not enable you to use breakpoints.
I suspect this is a problem with the classpath used for the GWT Development mode. Looks very similar to
http://osdir.com/ml/Google-Web-Toolkit/2009-11/msg01366.html
. If you have tomcat or other libraries in the (generated) launch configuration for GWT Development mode, remove them and try again.
I read “The offending Class was CompilerOptions. Simple fix was to put the GWT classpath before Tomcat’s” in the link, but how do I do that in Eclipse? I’m not sure what this means in a step-by-step way. How do I do this in Eclipse?
I also re-read the step-by-step for oophm: http://vaadin.com/wiki/-/wiki/Main/OOPHM%20Step%20by%20Step
But is that for the 6.3 experimental, too? I only seems to reference up to 6.2, and perhaps my mistake was to assume that the 6.3 had the oophm stuff inside there already.
In the GWT Development Mode “debug configuration” I move the ‘src’ (it was already there) above the default classpath, but I don’t see that I can re-arrange any of the entries in there.
Previously, I had missed the steps outlined in the oophm:
* Check: Build client side stub (skip this step if you are using Vaadin 6.2)
But I did this in the tutorial code buildMainLayout() by adding: getMainWindow().addComponent(new MyComponent());
It compiles fine, but the errors remain the same. Not sure what that generic component even does.
The oophm guide also says:
Add the gwt-dev-oophm.jar to user entries in the beginning of the list
But I don’t see that JAR – does this still need to be downloaded separately for 6.3 nightly?
One way should be to change the library order for the project:
This should automatically change the order in your launch configuration.
Vaadin 6.3 uses GWT 2.0 which has all the OOPHM stuff built in so you don’t need to change jars or manually download anything when using 6.3.
Awesome… that did it for me. Now I wonder about all the other little changes I made… . It took one refresh in the FF plugin since the first one “timed out” it seems, but then it came up just fine.
As an aside, what is the main value of oophm since I seem like I can debug my java vaadin code anyway when I plug in the URL from FF? I mean, I refresh the page and the debugger stops in init() for example, and I seem to be able to step around. Is there some limitation on that working that oophm resolves? Maybe like when trying to also debug GWT widgets that I build that are not vaadin widgets?
Without using the GWT Development mode (formerly known as OOPHM) you can debug server side code, i.e. your application class and everything related to that. Using GWT Development mode you can additionally debug the client side classes (widgets), i.e., everything that is compiled into javascript and runs in the browser. This is most useful when creating own widgets, if there is a problem with a Vaadin widget or if you are just curious how stuff works. As an example the TextField class can be debugged without any GWT help as it is run completely on server side. The corresponding widget, VTextField, cannot be debugged without development mode.
That makes sense, and is why it was such a blessing when GWT 2 came out and we were building UIs that way. I’m hopeful that Vaadin will keep us even further away, but it’s great to have the option now with 6.3.
Thanks for all the help that got my system configured and working wonders. Now to tackle the visual editor that looks like it can be helpful for us newbies, but then that wonderful tutorial exposed a lot of interesting bits to create a framework on which to work.