I've been having trouble lately with getting GWT dev mode to work. First I haven't been able to get IntelliJ 13 to work with dev mode on Mac, though it does work on Windows.
However, with the Firefox 27 release, the dev mode plugin no longer works. Apparently, this is going to be a permanent problem. And Chrome is soon to follow as Google will no longer be allowing access for those types of plugins.
So, the solution is supposed to be to use Super Dev Mode. However, as I said, I can't get this to work at all. I've tried through the IntelliJ IDE, but it looks like they've removed the Super Dev Mode checkbox when creating a new debug configuration.
So, I tried on the command line. Looks something like this:
java -cp $CLASSPATH com.google.gwt.dev.codeserver.CodeServer -port 6667 -workDir ~/gwt-work -src ~/src/myProject/src/main/java org.foo.myProject.web.MyProject
But, all I get is a stack with this:
[ERROR] Unable to find 'com/google/gwt/user/User.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?
Classpath has all the jars from my project WEB-INF/lib directory as well as all the gwt SDK jars. I'm kind of at a loss right now.
TL;DR How the hell do you get Super Dev Mode to work?
Here is great answer related to super dev mode. Check this out
Getting started with the SuperDevMode
This should solve your problem
Related
I am trying to disable the CompactStrings feature of Java 9 using the VM option: -XX:-CompactStrings, but it does not work.
When I tried to debug my application, the COMPACT_STRINGS variable in String class is always true (with or without the VM option)
I have the latest version of Java 9: jdk-9+181
And the Netbeans IDE Build 201709070001
I tried various options to set the VM option and none of them works.
What I tried is:
setting the VM option in app.conf, setting it in project.properties, running netbeans by ./netbeans -XX:-CompactStrings, setting the JVM option in Project->Properties->Run->VM Options
Is this a bug in Netbeans? Or am I doing something wrong?
I tried to reproduce your problem using a trivial "Hello World" Java application. However, toggling the CompactStrings feature in the project properties settings worked fine for me, and caused COMPACT_STRINGS to be set appropriately, so this is not a bug in NetBeans.
Although I am using the same version of Java (181) as you, I have a more recent Dev Build of NetBeans (Build 201709220002), and there are several discrepancies between my project properties screen and yours. For example, mine shows the Runtime Platform field but yours does not:
Something else to check is that you really do have the environment you expect. I find it easy to mess things up when multiple versions of Java and Netbeans are installed.
This is what I see when I do Help -> About:
If your environment looks fine then I can only suggest that you download the latest DEV Build of NetBeans and try again.
I was evaluating MGWT for the new mobile version of our website. So I downloaded the MGWT's showcase project and set it up in my Eclipse. I was able to compile the project and run it. I was then trying to set up the showcase to run in the Super Dev Mode environment which would help improve the development speed a lot. I followed the steps in Daniel's blog: http://blog.daniel-kurka.de/2012/07/mgwt-super-dev-mode.html.
Everything was fine. I was able to start the Codeserver. I was able to see the Super Dev Mode popup when I opened up the app. I was able to request the Codeserver to recompile and I could see the compilation messages in the console. I could also see the generated JS files of the recompilation.
However, it seemed that the Codeserver did not pick up the changes I made. I tried to change a simple text, then asked the Codeserver to recompile, but the changes did not show after the recompilation. When I checked the new generated JS files, I could see that the Codeserver still used the old code to recompile.
When I restarted the Codeserver, the changes were recompiled correctly and I could see them in the app.
If anyone has a clue of what I might have done wrong, please let me know. I appreciate your help very much.
Thanks
Just happened to find a solution to my own question:
Instead of adding the source folder to the classpath of the Codeserver run config as in Daniel's instructions, I added this source folder as part of the command line arguments using the -src argument (see here for more info).
So the arguments string for the Codeserver launch config should look like:
-bindAddress <codeserver-ip-address> -src <gwt-source-path> <gwt-module-name>
I've got a Android AppEngine Connected Project I'm trying to build using GWT2.4 RequestFactory and Objectify on my Eclipse IDE.
Apparently I need to run the RequestFactory Validation Tool because I'm using ServiceName and ProxyForName annotations (these are required especially when working on the Android client side). My problem is the Eclipse can't validate it and the solution provided at http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation#IDE_configuration is enough to make me rip my eyes out.
Since I'm working on a Windows machine, the shell script provided is not very useful. Trying to run Validation Tool from a cmd propt returns the error message:"This tool must be run with a JDK, not a JRE"
Can someone explain how this Tool is supposed to be run? Is there a way to use it as an External Tool in eclipse?
Normally if you follow carefully the instructions in the link you show, and run the GWT Development Mode from Eclipse, the Validation should be done automatically at the time you access the development URL with your browser.
For the record, I've actually had some problems with it, but launching the application several times maked it work.
Well, I ran into the same problem as well. When I tried annotation processing (under Java Compiler-> Annotation processing )was being disabled. So RequestFactoryDeobfuscatorBuilder was not being generated. Try enabling that and rebuilding your project.
I've just recovered from two days of hunting this bug down in a project that used to run validation properly but stopped.
In my case I had a new-ish generic BaseRequestContext and a specific sub-interface that extended it. My parent interface declared a method that didn't match the Locator's exactly (e.g. getThing(T) vs get(T)) and this wasn't reported as an error but did stop the validation tool from completing.
Apt is also removed in Java 8 : http://openjdk.java.net/jeps/117 . So beware.
Switching back to Java 7 will fix the issue if you are using Java 8.
I understood why the error happens sometimes in a project: the compiler was complaining it cannot find the directory .apt . But when I tried to create it manually it was not possible (under windows). I think the validation tool mutes the exception of not being able to create the directory: try renaming .apt in your validation tool calls (do a text search in your project)
I recently attempted to set new breakpoints in eclipse to debug service side code in GWT. For some reason eclipse refused to see the breakpoints or the new code changes I had made. In the debugger it would open up what appeared to be an ear file from somewhere. Even though I had deleted the old ears, compiled and redeployed the new ear files. We are using GWT 2.1, JBoss 4.3, java 1.6 and Eclipse Helios. Finally, when I created a new environment with the code from scratch it started working. Any ideas as to what was holding on to the old code? BTW, I had rebooted my machine and restarted eclipse, but it also didn't make any difference.
Thanks,
James
Current state of debugging GWT apps is ... well not really good. Sometimes it's incredibly slow (development mode), sometimes lot of rubbish stays at webserver.
This might not solve your problem directly, but here are some advices from me:
Writing new client code (/client) at GWT means refreshing browser
Writing new server code means "Reloading web server". You have little yellow "refresh" button in Eclipse in "Development Mode" tab. This should reflect all the changes done at server side.
Embedded Jetty works usually well with GWT debugging. If you are not doing something jboss-server-specific, it should also work fine at production server. Just make sure your unit tests pass ;-)
You can ofcourse debug GWT application on external server, see this section of documentation (I guess you do on JBoss)
Be sure to remove all old files when reloading web server. It happened to me, that sometimes there were some weird old mixed up files (I was using Tomcat though). So you might want to write own clean script.
You must be absolutely sure that your serever code even launched! Use lot of GWT.log() at client side, that will ensure you in this. Don't worry, GWT.log are ommitted in production mode.
Be sure to inspect client-side page, it sometimes help to find out that your server code didn't manage to launch.
Log every public void onFailure(final Throwable caught) { of your AsyncCallbacks to get more info.
Don't use Google Chrome in development mode. It's MUCH slower than Firefox.
Otherwise, if you're using most recent version of your application, Eclipse must stop at breakpoint correctly.
I think JBoss was somehow caching things in it's temporary files and then I had forgotten about adding source in. This may be a JBoss thing as I don't recall seeing it with other application servers before.
So after I cleared out the cache, what got me thinking about the source was the fact that eclipse would stop on the breakpoints in the debugger that I had just set, but I couldn't see the source files.
Prior to this I was apparently hitting the breakpoints in the cached files and I couldn't alter them by setting new breakpoints. That was the root cause of the issue. Then by adding in the source from the ear, I got the debugger in sync with the code and it started working fine.
I'm ramping up on Vaadin and I'm getting this javascript alert whenever I try and run the demo apps.
GWT module 'com.vaadin.terminal.gwt.DefaultWidgetSet' may need to be recompiled
I've tried cleaning the project to no avail.
As I said, I'm ramping up so I'm sure there's some simple step I'm missing or a concept I haven't grasped.
I don't know anything about Vaadin, but there's a more general context in which this error occurs:
So long as you're testing in Eclipse, the dynamic coding of your app is still real Java coding being run in a JVM. This coding is made available through debugger that's accessible via a socket. You get a URL that looks like this:
http://127.0.0.1:8888/MyApp.html?gwt.codesvr=127.0.0.1:9997
with this codesvr thing being your eclipse-hosted debugger process for your Java code.
Before your app can run standalone, GWT has to translate your Java code to JavaScript; separate versions of the code are produced for each browser type (Firefox, WebKit, Opera, ...) and language that you want to support. Only once this is done can you access your app the usual way via
http://127.0.0.1:8888/MyApp.html
After weeks of running my app only in Eclipse, I'd managed to forget about the compiling-for-browsers step and wondered about the message. The way to fire up the compiler, if you're not using the Ant task, is to hit Google|GWT Compile in the project's context menu. That done, the JS in your app gets fleshed out and your app can run without Java on the client side.
And of course the message goes away.
It is a warning not an error. Does the app work? Otherwise you have to recompile the Vaadin widgetset. These might help too: http://vaadin.com/directory/help/using-vaadin-add-ons
Often this message meens:
you're missing the ?gwt.codesvr=127.0.0.1:9997 parameter in the URL (or have misspelled it).
your module uses the xs linker <add-linker name="xs" />. This is a known limitation and will be fixed in the future: Issue 4232: Allow Development Mode to work with XS Linker
You may need to clear the browser cache. It is possible that the compiled js that the browser is using is not the js that has most recently been compiled.
In Chrome you can see if the cached js is being used in the developer tools windows (ctrl + shift + i). In the size column it will say (from cache) instead of the actual size. You can then right click and clear the browser cache. ctrl + r to reload and the error should be gone.
Carl Smotricz is absolutely right.
Just Cleaning and Build Project on the topmost menu doesn't work.
You must use "Google | GWT Compile" on the context menu generated when right-clicking on your GWT project, prior to deployment.
The error may not be about not-adding "?gwt.codesvr=127.0.0.1:9997" at the end of host web page if he or she tried to deploy the GWT-based webapp on WAS external to Eclipse.
Server restart did the job for me.
I had tried clearing cache, clean and rebuild .. but i was still getting the same warning message.
Server restart made it reload all the stull from the latest compiled war.
It was a hit and trial and i am glad it worked :) :)