> > This is just one of the encountred issues: it also happened to me that the > breakpoint didn't stop when I've put it inside a click handler, I never > understood why but I had to do a workaround. Sometimes I put the breakpoint > on a java source and it breaks in the js code instead..!?? >
No idea. Maybe these are just source map issues. I think with Chrome 38+ you see gray and white lines when opening a source mapped java file. Grey lines mean that no source mapping is available for that line and thus you can not put break points onto it. So sure there's a learning curve and a jump has to be done here, but let's > not forget that the strength of GWT was to write in java and have a js > compatible to all browsers. Now we have: write in Java in your usual tools, > but leave you environement when you'll have to debug and by the way, learn > all the js tricks and learn the chrome dev tools, and then also learn how > to read the values in js. Also eventually keep calm since the tools are not > always stable :). I mean, the "kepp your java skills and we'll handle the > js" is not that true anymore... > With IntelliJ 14 you can attach to Chrome/Firefox and set breakpoints in IntelliJ. For eclipse you can use the experimental SDBG plugin from github. Obviously you still debug Javascript as the IDE just connects to the browser using its debug protocol. So variables names or conditional break point expressions are all JS. However even with classic DevMode where are times where you need to debug JS. GWT is a leaky abstraction, you need to know CSS, HTML, JS at some point. You don't have to be expert but basic knowledge helps a lot. With SuperDevMode you are now closer to your real target environment. With classic DevMode you always had the risk that everything works in DevMode (because the real Java JVM classes are used) but fails once it is compiled to JS and executed in the browser (because of a bug in GWT's emulation of JRE classes). > Actually I started the code server separately then when I launched with > eclipse I found eclipse was launching the code server with no need for my > separate launch. I therefore assumed it was kind of harcoded in the plugin. > > The most stressing point on this is that I have to guess to understand > what is happening. Documentations are quite brief with step by step > description but no explaining that -noserver will allow you to launch your > code server alone. > > I know how hard it is for someone who knows well a product to write a lear > documentation, since there are a lot of assumptions that things are obvious > (where actually they are not and the reader may not even know the thing > exists at all). > With 2.7. things are not that different than with classic DevMode. When you launch the DevMode class in 2.6. it spawns an embedded jetty server and a process that listens for connections from the browser plugin. With DevMode -noserver you tell DevMode to not launch Jetty since you want to use your own server. With 2.7. its literally the same. The only difference is that instead of listening for a browser plugin the CodeServer class will now be launched (and with -nosuperdevmode you get back classic DevMode). But yeah, GWT documentation could be better. Feel free to volunteer :) I think the SuperDevMode article has been updated a bit recently, but IMHO it is super hidden: http://www.gwtproject.org/articles/superdevmode.html -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
