Back when GWT was all new and shiny (almost three years ago), I played with it and put together a tiny library of Ant tasks - nothing earth-shattering, really basically only a few macrodefs over Ant's java task.

Strangely I still get quite a few hits by searches for "GWT and Ant", so it seems as if nobody else has given GWT and Ant integration a try.

I don't use GWT. Not at all. When I create webapps at $JOB GWT isn't the right choice, either its technology is no fit (we mainly are a .NET shop after all) or the layout requirements can't be achieved by any component based framework I've tried (so far it is Velocity at the view layer for me).

Almost exactly two years ago Fernando Meyer sent me a patch to the Antlib that changed the hard coded directory names for source and destination into attributes on the gwt:shell and gwt:compile tasks. About a year ago I was asked how one could increase the memory size for gwt:compile. Somewhere very deeply buried on my TODO list I took note of them.

When I woke up this morning Apache's svn was read-only and suddenly I had time (I planned to hack on Gump) but no ASF project to keep me occupied so I finally managed to integrate Fernando's patch and make room for arbitrary extension arguments.

Code and sources are here and while I was at it, there is a darcs repository1 for it (I've been using darcs for years and didn't feel like installing a different SCM backend).

gwt:compile and gwt:shell have new attributes sourcedir that default to the old hard-coded value "src" for the source directory and both have a new nested element jvmargs that can be used to pass arbitrary nested elements supported by Ant's java task to the underlying task. I.e. one can now write

    <gwt:compile outDir="www" gwtHome="${gwt.home}"
                 classBase="de.samaflost.gwt.Foo">
      <gwt:jvmargs>
        <jvmarg value="-Xmx1024m"/>
      </gwt:jvmargs>
    </gwt:compile>

in order to bump the max memory to one gig. gwt:shell now also has an optional bindir attribute defaulting to the old hard-coded "bin".

The Antlib has seen some minimal manual testing against GWT 1.5.

It should be obvious that I don't really maintain these tasks, and to be honest I don't expect I'll ever do. If anybody wants to fork the code, reuse it, whatever, feel free to do so. If you are planning to maintain a more useful Ant integration than my hackish version did, please let me know so I can send people looking for "GWT and Ant" your way.

[1] The directory is not browseable, use

darcs get http://stefan.samaflost.de/repos/gwttasks/

in order to grab the contents.

path: /en/Java/GWT | # | Writebacks

First I must admit that I don't buy GWT's approach. There is a reason why we don't write HTML code from servlets anymore. Programmers usually are bad UI designers (look at my website for something to back my claim ;-) and great UI designers usually don't want to write Java code. With the GWT model you write your UI in Java and automatically translate it to HTML. This means layout changes require the Java coder to perform it, which is bad. Maybe you can get around most problems with the help of CSS, but I doubt that.

Anyway, I downloaded the toolkit and played with it last night, and found it to be a bit cumbersome to work with. Scripts that generate scripts and no integration with Ant to speak of.

I stopped after my first few steps and started to put together a little Ant library that makes using GWT a bit less cumbersome - at least to me. This is very rough alpha level code, but it works for me. I'm not sure I'll take this any further, but if anybody is interested in it, feel free to use the code - the license is pretty permissive. Source and binaries are available here.

There is no documentation right now. A quick rundown:

Reading this a second time, it is a bit confusing, I guess.

You must provide a class name to Google's applicationCreator script, let's say you've chosen de.samaflost.client.Dummy (the .client. piece is recommended by Google), then gwt:compile's classBase would be de.samaflost.Dummy and 's startPage would be de.samaflost.Dummy/Dummy.html.

Putting the stuff together. To seed a new GWT application you'd use

  <target name="applicationCreate">
    <mkdir dir="project"/>
    <gwt:applicationCreator dir="project"
      gwtHome="C:/OSS/gwt-windows-1.0.20/"
      className="de.samaflost.client.Dummy"/>
  </target>

This will generate the initial directory structure in the project subdirectory and will also generate an Ant build file that contains (among other things)

  <target name="gwt-compile" depends="compile">
    <gwt:compile outDir="www" gwtHome="C:\OSS\gwt-windows-1.0.20"
      classBase="de.samaflost.Dummy"/>
  </target>

  <target name="gwt-shell" depends="compile">
    <gwt:shell outDir="www" gwtHome="C:\OSS\gwt-windows-1.0.20"
      startPage="de.samaflost.Dummy/Dummy.html"/>
  </target>

This means you don't need to worry about classBase or startPage at all. It also means you now have the Java -> JavaScript step as part of your Ant build process and available to your continuous integration runs.

I haven't found the time for an actual RPC example yet, but expect it will lead me to a special gwt:war task that knows what to package where.

Finally, it may be worth noting that three of the four tasks are implemented in Ant, not Java (i.e. they are <macrodef>'s hidden in the antlib descriptor.

path: /en/Java/GWT | # | Writebacks