Tag Archives: appengine

Google's GWT 2.0.4 Available on Maven Central (via Nexus OSS)


July 19, 2010 By hloney

Sonatype is happy to announce that Google Web Toolkit 2.0.4 jars are now available in the Maven Central repository.  The Google Web Toolkit blog explains this move in more detail:

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.

Continue reading →

My Google App Engine Maven Plugin Wishlist


April 10, 2009 By justin

Now that I’ve had a few days to start using with Google App Engine’s Java support, some patterns are emerging and it’s becoming clearer what the lifecycle elements of an App Engine application is. Here’s the initial list of goals of what I’d like to see in a GAE Maven Plugin:

  • 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.