Better maven support has been frequently requested on the issue tracker and mailing list, and this is a first step in that direction. In the future, Google will publish GWT releases to maven central as part of the release process.

The GWT 2.0.4 jars currently in the repository include gwt-user, gwt-dev, and gwt-servlet.    To publish these artifacts in the Maven Central repository, Google publishes artifacts to Nexus OSS, the Open Source oss.sonatype.org repository.   You can see the Google-specific repository on this server here.   Releases are staged to this Google repository on oss.sonatype.org and then subsequently released and synchronized to the Maven Central repository.

Configuring the GWT Plugin

To start developing with GWT, take a look at the “Automatic Mode Setup” section on the GWT Maven plugin’s Setup instructions.   Before last week, the only way to develop a GWT application with the latest version of GWT was to download the SDK to your workstation and then use systemPath dependencies or a custom task to publish artifacts to your local repository.    Today, you can just point your Maven project’s pom.xml at the correct version of gwt-servlet and gwt-user and Maven will grab the necessary native libraries from Central.

This doesn’t just make GWT development easier and more straightforward for people already using the tool, it will make it much easier for developers to start using GWT.   When you publish your project’s artifacts to the Maven Central repository you make it easier for people to adopt your technology.   Maven Central is the “dial tone” for most developers, and if you put it on Central, they can access it without having to download an SDK or configure a build system.   Maven Central just works.

Nexus OSS is the fastest, most efficient way to publish artifacts to Maven Central, and Sonatype has made this service available to any open source project that needs to publish artifacts.   If you work with an open source project or a company which publishes open source libraries, read the Sonatype Nexus OSS Repository Guide to get started.

• gae:run – analogous to jetty:run. Runs a WAR project on the GAE dev appserver. Ideally has all the same reloading features that we know and love from the Jetty plugin.
• gae:start / gae:stop – this might be accomplished by creating a Cargo adapter for GAE’s dev appserver.
• gae:update – Deploys a project to GAE.
• gae:generate-appenginexml – Generate the appengine-web.xml file.
• gae:enhance-classes – perform the necessary DataNucleus byte code enhancement.

But the big one is some kind of processing that will let you know if your application uses classes not in the App Engine whitelist. The application I (perhaps foolishly) ported was an image manipulation application that uses some AWT classes internally. And a number of people have run into the Spring’s dependency upon JNDI when JPA is present. Neither of these issues came up when running the dev appserver locally. Even if they had, it’d be great to discover these types of issues at compile time, instead of at run time.

Anyone else have good goal ideas? Post them in the comments.