GWT 2.7.0 RC1 available

[Daniel Kurka]

Hi all,

I just build the GWT 2.7.0 RC1 and pushed it to maven central. The complete SDK is also available from here.

Please start testing and let us know if you run into any trouble. You can either reply to this thread on gwt-contrib or file a bug.

We are planing to release this as GWT 2.7.0 if we do not here about any serious issues within the next two weeks. The release notes for RC1 will be made available shortly after this notice, in the mean time you can take a look at the review for the release notes.

Daniel,

on behalf of the GWT team

[Matt Wallis]

Hi Daniel.

I'm now using 2.7.0-rc1, and incremental compilation is working (Hoorah!). I'm launching the codeserver from the command line (mvn gwt:run-codeserver), and running the in-browser compilation from Chrome using new bookmarklets. So far so good.

However, if I add a new source file, it is not found by incremental compilation. As a work-around, I restart the codeserver (which causes a full recompilation), and then next time I compile from within the browser, another full compilation is also necessary. Then finally, after 2 full recompilations, I'm back with the benefits of incremental compilation.

Is this to be expected, or does it indicate that I don't have things configured properly? If this is the expected/current behaviour, then is there a better work-around (that does not require 2 full recompilations)?

Best regards,
Matt.

[Matt Wallis]

On 30/10/2014 16:38, Matt Wallis wrote:
>
> However, if I add a new source file, it is not found by incremental
> compilation.

Update: Now I can't repeat this, having added another new source file.

[Daniel Kurka]

There is no need to start the codeserver directly anymore, its now started by default when you launch the old dev mode.

And you do not need to use the bookmarklets in that mode anymore. It just recompiles automatically.

See: https://www.youtube.com/watch?v=qpCSbj36O44

[Edu]

Automatic recompiles when refreshing aren't working for me. My server side is .Net and my web server is IIS (running DevMode using -noserver). Maybe that feauture doesn't work it this scenario?

--
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-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Friday, October 31, 2014 11:05:57 AM UTC+1, Eduardo Guardiola wrote:

Automatic recompiles when refreshing aren't working for me. My server side is .Net and my web server is IIS (running DevMode using -noserver). Maybe that feauture doesn't work it this scenario?

You have to pass -launcherDir to the CodeServer and use the generated *.nocache.js instead of a precompiled "prod" version of the app.

When using a precompiled "prod" version of the app, then the behavior doesn't change and you have to use the bookmarklets to turn SDM on and off and recompile the app.

[rhmoller]

The gwt-dev-2.7.0-rc1.jar available through maven central has an empty org/objectweb folder. All the asm classes are missing.

The classes are present in the zipped version

/Rene

[Raphael Garnier]

Hi, 

I also use SDM with -noserver and I don't know wich directory I must chose to have the refresh feature active.

Here's the arguments : 

-remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -startupUrl http://localhost:8080/tablet.jsp -logLevel INFO -noserver -workDir "${resource_loc:/cassis-tablet/target/gwtc/work}" -launcherDir "${resource_loc:/cassis-tablet/target/gwtc/work/fr.agfahealthcare.cassis.CassisTablet/compile-1/war}" -war "${resource_loc:/cassis-tablet/target/cassis-tablet-1.0-SNAPSHOT}" -codeServerPort 8888 -bindAddress 0.0.0.0 fr.agfahealthcare.cassis.CassisTablet_dev

and the launch log  :

Runing CodeServer with parameters: [-noprecompile, -port, 8888, -sourceLevel, 1.7, -bindAddress, 0.0.0.0, -workDir, D:\Users\AWTCK\Documents\Developpement\Workspace\cassis\cassis-tablet\target\gwtc\work, -launcherDir, D:\Users\AWTCK\Documents\Developpement\Workspace\cassis\cassis-tablet\target\cassis-tablet-1.0-SNAPSHOT, -logLevel, INFO, fr.agfahealthcare.cassis.CassisTablet_dev]

As you said Thomas, I have to change the -launcherDir, but I don't know what to use ?

Thanks

[Thomas Broyer]

On Friday, October 31, 2014 1:48:09 PM UTC+1, rhmoller wrote:

The gwt-dev-2.7.0-rc1.jar available through maven central has an empty org/objectweb folder. All the asm classes are missing.

The classes are present in the zipped version

Yes, when we deploy to Central, we strip out ASM and declare it as a dependency instead.

(we used to do that for org.json too, but we have refactored the build)

[Jens]

I also use SDM with -noserver and I don't know wich directory I must chose to have the refresh feature active.

Here's the arguments : 

-remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -startupUrl http://localhost:8080/tablet.jsp -logLevel INFO -noserver -workDir "${resource_loc:/cassis-tablet/target/gwtc/work}" -launcherDir "${resource_loc:/cassis-tablet/target/gwtc/work/fr.agfahealthcare.cassis.CassisTablet/compile-1/war}" -war "${resource_loc:/cassis-tablet/target/cassis-tablet-1.0-SNAPSHOT}" -codeServerPort 8888 -bindAddress 0.0.0.0 fr.agfahealthcare.cassis.CassisTablet_dev

You don't need that parameter if you launch the DevMode class. When launching DevMode it will configure the CodeServer -launcherDir parameter to the same value as DevMode -war . That way SDM will copy all public resources and the <module>.nocache.js file into your exploded war directory, just like classic DevMode did. 

 

and the launch log  :

Runing CodeServer with parameters: [-noprecompile, -port, 8888, -sourceLevel, 1.7, -bindAddress, 0.0.0.0, -workDir, D:\Users\AWTCK\Documents\Developpement\Workspace\cassis\cassis-tablet\target\gwtc\work, -launcherDir, D:\Users\AWTCK\Documents\Developpement\Workspace\cassis\cassis-tablet\target\cassis-tablet-1.0-SNAPSHOT, -logLevel, INFO, fr.agfahealthcare.cassis.CassisTablet_dev]

Here you see that CodeServer is launched with your target folder as -launcherDir. Your target folder is probably your exploded war folder. So that seems correct. However it might be that you have an old/outdated (GWT 2.6.1) <module>.nocache.js file in your target folder. So try a clean and try again.

-- J. 

[Thomas Broyer]

On Friday, October 31, 2014 2:10:14 PM UTC+1, Raphael Garnier wrote:

Hi, 

I also use SDM with -noserver and I don't know wich directory I must chose to have the refresh feature active.

Here's the arguments : 

-remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -startupUrl http://localhost:8080/tablet.jsp -logLevel INFO -noserver -workDir "${resource_loc:/cassis-tablet/target/gwtc/work}" -launcherDir "${resource_loc:/cassis-tablet/target/gwtc/work/fr.agfahealthcare.cassis.CassisTablet/compile-1/war}" -war "${resource_loc:/cassis-tablet/target/cassis-tablet-1.0-SNAPSHOT}" -codeServerPort 8888 -bindAddress 0.0.0.0 fr.agfahealthcare.cassis.CassisTablet_dev

and the launch log  :

Runing CodeServer with parameters: [-noprecompile, -port, 8888, -sourceLevel, 1.7, -bindAddress, 0.0.0.0, -workDir, D:\Users\AWTCK\Documents\Developpement\Workspace\cassis\cassis-tablet\target\gwtc\work, -launcherDir, D:\Users\AWTCK\Documents\Developpement\Workspace\cassis\cassis-tablet\target\cassis-tablet-1.0-SNAPSHOT, -logLevel, INFO, fr.agfahealthcare.cassis.CassisTablet_dev]

As you said Thomas, I have to change the -launcherDir, but I don't know what to use ?

Well, either you use DevMode and use -war, or you use CodeServer and use -launcherDir (as you saw, DevMode's -war is passed as -launcherDir to the spawned CodeServer –actually running in a thread, not a child process–, and if you had passed -modulePathPrefix to DevMode, it would have been appended to the -war before being used as -launcherDir). When you used -noserver with DevMode, you can now switch to CodeServer, as DevMode has no added value in this case (unless you need to switch back to -nosuperDevMode from time to time).

Anyway, the -launcherDir needs to be served by your "external" server so that the browser loads the *.nocache.js that's just been generated and both must run on the same host (knowing that project, that should be the case).

[Raphael Garnier]

It works fine by adding in my CodeServer configuration :

-launcherDir ${resource_loc:cassis-server/target/cassis-server-1.0-SNAPSHOT} 

Reading Daniel, I thought that we had to use DevMode instead of CodeServer.

But I don't know if it is possible to change the project-version by a variable !

Thanks for your help.

[Edu]

Thanks Thomas. It was really easy. My fault.

--

[Florian Friemel]

Hi, 

about the java 8 support:

When I try to compile a project that uses java 8 features I get an error like the following: 

   Tracing compile failure path for type 'com.example.SomeClass'
      [ERROR] Errors in 'file:src/com/example/SomeClass.java'
         [ERROR] Line 31: Lambda expressions are allowed only at source level 1.8 or above
   [ERROR] Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly

The project sdk and language level are java 8.
I tried to set the sourceLevel to 1.8, but when I compile with  '-sourceLevel 1.8' I get

   Source level must be one of [auto, 1.6, 1.7].
   Google Web Toolkit 2.7.0-rc1
   
So, is java 8 support just not there yet or am I missing something? If not, will it be in the final release?

[Juan Pablo Gardella]

It's not supported yet.

[Florian Friemel]

any info on when it will be supported?

On Monday, November 3, 2014 2:02:50 PM UTC+1, Juan Pablo Gardella wrote:

It's not supported yet.

On 3 November 2014 09:42, Florian Friemel <florian...@gmail.com> wrote:

Hi, 

about the java 8 support:

When I try to compile a project that uses java 8 features I get an error like the following: 

   Tracing compile failure path for type 'com.example.SomeClass'
      [ERROR] Errors in 'file:src/com/example/SomeClass.java'
         [ERROR] Line 31: Lambda expressions are allowed only at source level 1.8 or above
   [ERROR] Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly

The project sdk and language level are java 8.
I tried to set the sourceLevel to 1.8, but when I compile with  '-sourceLevel 1.8' I get

   Source level must be one of [auto, 1.6, 1.7].
   Google Web Toolkit 2.7.0-rc1
   
So, is java 8 support just not there yet or am I missing something? If not, will it be in the final release?

--
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+unsub...@googlegroups.com.

[Jens]

any info on when it will be supported?

GWT 3.0 will have Java 8 language support, there is already a patch providing lambda/method references: https://gwt-review.googlesource.com/#/c/9260/

How many Java 8 APIs will be emulated at the time GWT 3.0 will be released is a different story.

GWT 2.7. is all about faster SuperDevMode which had higher priority since browsers are dropping APIs required for classic DevMode.

-- J.

[Zied Hamdi OneView]

Hi Daniel,

It's good to have GWT super dev mode in many aspects. But there are still some issues that made me decide to go back to the 2.6.1, some of them are critical:

 1- First of all, I actually have a problem with my huge project, and the browser says: 

Uncaught com.google.gwt.core.client.JavaScriptException: (RangeError) : Maximum call stack size exceeded Impl.java:286entry0_0_g$ Impl.java:286(anonymous function)

How can I ever guess what's wrong with the app, or where to put a breakpoint with this???

 2- Second argument: it's true the recompilation is blazing fast. But in the developement phase it is very common to add or remove methods (on the server side), or to do things the JVM cannot handle without restart. So I've found I'm loosing a lot more time than in the emulated mode, since the first page display is always very very very long (above 2 minutes), and this gets the developer distracted and forgetting what he wanted to do.

So as a conclusion, I think there are improvements to do in the browser developer tools still : even if a lot of things have bee done, we are still very far from the eclipse experience, and some errors are just unrecoverable (like the one cited in point 1)

Maybe removing the dev mode from the 3.0 version will make the entire version a fail since people will not adopt it, they will majoritairily remain in the 2.6 (except for small projects)

[Jens]

 1- First of all, I actually have a problem with my huge project, and the browser says: 

Uncaught com.google.gwt.core.client.JavaScriptException: (RangeError) : Maximum call stack size exceeded Impl.java:286entry0_0_g$ Impl.java:286(anonymous function)

How can I ever guess what's wrong with the app, or where to put a breakpoint with this???

Tell Chrome to stop on any exception (in DevTools under "Sources" the small sign button on the right).

 

 2- Second argument: it's true the recompilation is blazing fast. But in the developement phase it is very common to add or remove methods (on the server side), or to do things the JVM cannot handle without restart. So I've found I'm loosing a lot more time than in the emulated mode, since the first page display is always very very very long (above 2 minutes), and this gets the developer distracted and forgetting what he wanted to do.

Use DevMode -noserver or start CodeServer directly. Obviously you need a local app server then to serve your server side code. We do it that way (to have the same production env locally) and I rarely restart my CodeServer. Also take a look at: https://gwt-review.googlesource.com/#/c/9450/

-- J.

[Zied Hamdi OneView]

Ok thanks Jens, great to know that (especially for the second point)

Le mardi 11 novembre 2014 10:48:10 UTC+1, Jens a écrit :

 1- First of all, I actually have a problem with my huge project, and the browser says: 

Uncaught com.google.gwt.core.client.JavaScriptException: (RangeError) : Maximum call stack size exceeded Impl.java:286entry0_0_g$ Impl.java:286(anonymous function)

How can I ever guess what's wrong with the app, or where to put a breakpoint with this???

Tell Chrome to stop on any exception (in DevTools under "Sources" the small sign button on the right).

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..!??

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...

 

 

 2- Second argument: it's true the recompilation is blazing fast. But in the developement phase it is very common to add or remove methods (on the server side), or to do things the JVM cannot handle without restart. So I've found I'm loosing a lot more time than in the emulated mode, since the first page display is always very very very long (above 2 minutes), and this gets the developer distracted and forgetting what he wanted to do.

Use DevMode -noserver or start CodeServer directly. Obviously you need a local app server then to serve your server side code. We do it that way (to have the same production env locally) and I rarely restart my CodeServer. Also take a look at: https://gwt-review.googlesource.com/#/c/9450/

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).  

[Jens]

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.

[Alfred S]

What's the reasoning behind deprecating GWT Designer? I feel like it was a useful tool, especially for beginners. It helped me sell the idea of using GWT on some projects.

[Alfred S]

Nevermind - I found this discussion.

[Bu Pereira]

Plus, it's a great editor to create screens quickly and on-the-fly. I second your opinion.

--

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-tool...@googlegroups.com.

[Kable Wilmoth]

Also, it was just added back in, in the last release.  I was hoping to use this as a simple drag-n-drop UI editor for a web building application for non programmers.

Would like to know why it was removed.

-kable

On Tuesday, November 11, 2014 10:58:48 AM UTC-8, Bu Pereira wrote:

Plus, it's a great editor to create screens quickly and on-the-fly. I second your opinion.

On Tue, Nov 11, 2014 at 12:32 PM, Alfred S <alf...@sterphone.com> wrote:

What's the reasoning behind deprecating GWT Designer? I feel like it was a useful tool, especially for beginners. It helped me sell the idea of using GWT on some projects.

On Wednesday, October 29, 2014 8:05:30 PM UTC-4, Daniel Kurka wrote:

Hi all,

I just build the GWT 2.7.0 RC1 and pushed it to maven central. The complete SDK is also available from here.

Please start testing and let us know if you run into any trouble. You can either reply to this thread on gwt-contrib or file a bug.

We are planing to release this as GWT 2.7.0 if we do not here about any serious issues within the next two weeks. The release notes for RC1 will be made available shortly after this notice, in the mean time you can take a look at the review for the release notes.

Daniel,

on behalf of the GWT team

--
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+unsub...@googlegroups.com.

[Jocelyn Pelletier]

Is it me or the "dev mode off" button is not working?