Friday, June 27, 2014

Compiling GWT applications on Windows

If you're a developer using Microsoft Windows and you've ever developed a GWT application of any size you've probably encountered the command-line length limitation (

The gwt-maven-plugin constructs a command line statement to invoke the GWT compiler containing a list of what can be a very extensive classpath declaration. The length of the command line statement can easily exceed the maximum supported by Microsoft Windows; leaving the developer unable to compile their GWT application without resorting to tricks such as mapping a drive to their local Maven repository thus shortening the classpath entries.

Hopefully this will soon become a thing of the past!

I've submitted a Pull Request to the gwt-maven-plugin project to provide a more concrete solution. With this patch the gwt-maven-plugin is able to compile GWT applications of any size on Microsoft Windows without developers needing to devise tricks.

Until the pull request is accepted and merged you can compile kie-drools-wb or kie-wb by fetching my fork of the gwt-maven-plugin and building it locally. No further changes are then required to compile kie-wb.

Happy hunting!



  1. No, to be honest, I've not tried it (to be even more honest I don't use Windows... but thought to try to provide a solution to those who do and cannot compile kie-wb). Thanks for the information though; someone searching for a solution will come across your suggestion!

  2. I hit this issue with gwt-maven and tried running mvn from console2 but still had the same issue.

  3. I have hit this same problem, and have tried all suggestions out there eg:
    still no luck.

    Noting having used Maven extensively - What are the actual steps needed to "fetching my fork of the gwt-maven-plugin and building it locally."

    Thanks very much in advance.

  4. Hi Michael, I'm trying to use your fork, but is not building. Do you have some suggestion to make it work?

    Thanks a lot.

  5. There's a problem with your fix, namely the verify.groovy script which fails on:

    assert !content.contains('ERROR');

    due to there being some environment variable ERROR_something being written in the log, changing it to

    assert !content.contains('[ERROR]');

    fixes the problem.