Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

GWTTestSuite makes builds faster, but requires JUnit 4.1

Earlier this week, I spent some time implementing GWTTestSuite to speed up my project's build process. In Hudson, the project was taking around 15 minutes to build, locally it was only taking 5 minutes for mvn test. In IDEA, I could run all the tests in under a minute. While 15 minutes isn't a long time for a build to execute, a co-worker expressed some concern:

Does Maven have to run GWT test and individual Java processes? (See target/gwtTest/*.sh) This arrangement and the overhead of JVM launches is another reason why builds take so long. As we add more GWT tests we are going to test that LinkedIn record for the slowest build ever.

After this comment, I started looking into GWTTestSuite using Olivier Modica's blog entry as a guide. It was very easy to get things working in IDEA. However, when I'd run mvn test, I'd get the following error:

Error: java.lang.ClassCastException

No line numbers. No class information. Zilch. After comparing my project's pom.xml with the one from the default gwt-maven archetype, I noticed the default used JUnit 4.1, while I had the latest-and-supposedly-greatest JUnit 4.4. Reverting to JUnit 4.1 fixed the problem. Now Hudson takes 3:15 to execute the build instead of 15 minutes.

The reason for this blog post is this doesn't seem to be documented anywhere. Hopefully other developers will find this entry when googling for this issue.

Related to making GWT faster, I also added the following line to my Application.gwt.xml file:

<set-property name="user.agent" value="safari" />

This dropped the gwt:compile time from 1 minute to 25 seconds. As explained in the documentation, you can use the "user.agent" setting to only generate one JS file for your app instead of 4. The strange thing about adding this setting was I pretty much forgot about it since everything seemed to work fine on both Safari and Firefox. When I started testing things in IE6, I started seeing a lot of JavaScript errors. After debugging for an hour or so, I realized this setting was there, removed it, and everything started working great in all browsers.

Now if I could just figure out how to use safari-only for development, but remove the line when building the WAR. Suggestions welcome.

Posted in Java at Feb 27 2009, 11:58:12 AM MST 6 Comments
Comments:

Reverting to JUnit 4.4 fixed the problem.
You mean reverting to JUnit 4.1 right?

Posted by Peter Thomas on February 27, 2009 at 05:02 PM MST #

> You mean reverting to JUnit 4.1 right?

Yep! Thanks for the (very important) correction Peter.

Posted by Matt Raible on February 27, 2009 at 05:12 PM MST #

Use a profile for development/prod builds. Default should be for dev but add something like "-Dprod" to add in that property. You have your profile activate based on a property or do a "-Pprod" to activate the production version.

Posted by Jeff Genender on February 27, 2009 at 11:09 PM MST #

Jeff - I tried something similar, but I believe the value is read from the raw Application.gwt.xml before it's processed, so it doesn't work. In Application.gwt.xml, I added:

${user.agent}

In my pom.xml, I added filtering for this file:

    <resource>
        <directory>src/main/java</directory>
        <includes>
            <include>**/Application.gwt.xml</include>
        </includes>
        <filtering>true</filtering>
    </resource>

And I added a <user.agent> property:

<user.agent>
    <set-property name="user.agent" value="safari"/>
</user.agent>

The $[user.agent} token gets replaced correctly during resources:resources, but four MD5.cache.html get generated. Also, the user.agent property uses escaped XML for < and >, but I can't get it to show up properly in this comment.

Posted by Matt Raible on February 28, 2009 at 11:16 AM MST #

Matt,
You could always duplicate the Application.gwt.xml, i.e. have a ApplicationSafari.gwt.xml version, and then use parameter replacement in the compile section of the maven compile plugin, e.g.:

<compileTargets>
    <value>${gwt.compileTarget}</value>
</compileTargets>

and then specify

<gwt.compileTarget>org.appfuse.Application</gwt.compileTarget>

as a default, and

gwt.compileTarget=org.appfuse.ApplicationSafari

when you just want Safari output.

I suppose you could change this slightly and have just the Safari bit parameterised then it would work cross-project, and you could set it in your maven settings.xml file

Not as elegant as what you really want, but it should work ;-)

Posted by RoyPorter on March 02, 2009 at 08:26 AM MST #

There is a workaround that allows you to use GWTTestSuite with JUnit 4.4, see http://thinking-in-code.blogspot.com/2009/03/running-gwttestsuite-in-junit-44.html.

Posted by Dean Povey on March 18, 2009 at 07:16 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed