SpringIO with GWT 2.7

Question

Spring IO jar with embedded container fits like a glove with AngularJS as a UI. You can gunsling your static resources trivially with jar based spring io project (namely .html pages with angularjs or anyother javascript library).

For angular based front end SpringIO Web is really a perfect fit.

However, on the topic of having SpringIO packaged as a jar (not as a WAR) to cooperate with GWT built by maven, the problem seems to not be so easily solvable.

The only relevant answer on this topic so far is the following. Spring Boot + GWT embedded configuraiton

Indeed, if you were to just need to build a GWT application into a springIO jar (a productive jar), then one could live with simply making sure that the GWT javascript would fall into the appropraite META-INF/resources to be served to the client.

However, during development time when Java to Javascript compilation has yet to take place, and traditional the gwt:run plugin is used, it would be interesting to get an official response as to how a pom.xml should be properly setup so that:

(a) we use the embedded container of our choice tomcat or jetty

(b) during development time we get the benefit of container restart with the springio devtools. This works like a charm for Spring x Angular based programs where javascript resources are immidiately refreshed without a restar and class changes lead to a restart

(c) Still get to debug a GWT application without having to compile the full monster

I am wondering: Is the only way that person can develop productively using GWT and Spring IO at the same time is to state: - I need two containers. A front end jetty to run the GWT part along and serve the javascript and debug the front ent.

A back end application in spring IO where I have no javascript but can productively get my springboot dev tool to class change tomcat restarts.

and between the jetty and the embedded tomcat, integrate the two JVM containers using simple rest based web services. The Network cost is essentially redudant if both are on the same localhost. But, it is not a perfect world if to develop productively one would need a separate container that has GWT javascript and container that has the SpringIO business logic.

Would it be possible for springio to provie a GWT maven pom.xml so that one can work productively together using both GWT and SpringIO?

On my side, I must say I do not like the SpringIO WAr approach for which there is already a git project to demonstrate.

If the JAR SpringIO JAR with embedded container cannot be setup to lead to a productive development environment, I simply opt for two containers with the most effective development pom.xml for GWT fornt-end and busienss logic on springio backend. Many thanks for a reply on this.

Answer 1

You can easily run the SuperDevMode codeserver as a standalone application and it will recompile when you change anything in your GWT code (basically you end up with two containers: spring boot and the codeserver).
If you specify the launchDir to be where Spring Boot's looks up its static web resources, you just need to refresh the page to get a recompile. Otherwise you can always use the boormarklet to manually initiate a re-compile.

I would recommend to use Thomas Broyer's gwt-maven-plugin

Answer 2

In company where I work, we work with SmartGWT framework that is based on GWT. With this framework, we are easily integrated Spring on our project and you can easily debug/run project on SuperDevMode.

Answer 3

Proof of concept is:

Step (1) use gwt 2.7 web app creator to generate a sample gwt project with a proper pom. In this case doing a gwt:run already gives an OK development environment as far as seing client code refreshed upon change. Not bad but not enough.

Step (2) as proof of concept for spring boot dev tools server side refresh, go conservative and just add the jetty plugin to the pom. The jetty plugin gives you JRebel like configuration options that the GWT plugin lacks, even though it uses jetty. The GWT plugin does not allow you to express a scan interval for your classpath, whereas jetty does.

 <plugin>
      <groupId>org.eclipse.jetty</groupId>
      <artifactId>jetty-maven-plugin</artifactId>
      <version>9.3.0.v20150612</version>
      <configuration>
          <scanIntervalSeconds>10</scanIntervalSeconds>
          <webApp>
              <contextPath>/</contextPath>
          </webApp>
      </configuration>
  </plugin>

Step (3) as hinted by Umit, one is not forced to run gwt with the embedded container during development time. Instead, one can work just as productively doing something of the form: mvn war:exploded mvn jetty:run-exploded mvn gwt:gwt-codeserver

This is rather ideal, as to update code changes on the UI one can use the code server bookmark to trigger a recompilation. And for the server side core jrebel behavior, simply mvn exploded:war when code changes, or fix you mvn build output directory to go into the WEB-INF/classes ... anyway, and jetty will pikcup the file changes and restart web app class loader quickly.

The same principle has to work with Springboot...

And indeed it does.

When using GWT+SpringBoot as a JAR the trick is two fold:

(a) just like when using our own jetty:run-exploded instead of the jetty of gwt:run embedded jetty; the gwt plugin needs to be tuned to have

<noServer>true</noServer>

(b) The gwt plugin assumes you will package the APP as a war, which is not the case. Thefore, to make sure that the springboot app serves your nocache.js file, you must make sure you tune the gwt plugin with somehting of the form:

<webappDirectory>${project.build.directory}/classes/META-INF/resources</webappDirectory>

The line above is a matter of taste. Spring boot supports several folders for static resources, I simply use the same folder you would dump four JSF libraries inside of JSF components jar file in a JEE app.

In any case, it is clear the plugins for springboot and gwt are not well married together, but together both maven plugins give us enough configuration options to make the thing work out properly during development.

As for production mode, it is obvious it works, it is just a matter of packaging the resources into the right folders before geting the final jar assembled.

In the end, springboot + gwt works fine, with UI source reloading as well as back end fast class reloading, without being forced to deal with eclipse tailored plugins, maven takes well care of everything. Perfect match for Netbeans.