Using JAXB annotated classes with GWT and maven

When compiling GWT projects that make use of classes with JAXB annotations it typically works fine within the IDE, as you have the JDK source code available to the compiler. However, running the GWT compiler on the same project from e.g. maven or ant will fail since the JAXB annotations are not part of default java types understood by GWT. In a maven-based GWT project you can fix this by adding the following dependency within your POM file:

<dependency>
  <groupId>javax.xml.bind</groupId>
  <artifactId>jaxb-api</artifactId>
  <version>2.2</version>
  <classifier>sources</classifier>
  <scope>provided</scope>
</dependency>

Configuring Maven-based GWT projects for Eclipse

When developing with GWT and maven in Eclipse, you don't get the benefits of the Google Eclipse Plugin by default, as maven and the Maven GWT plugin doesn't configure your Eclipse project settings to work with the GWT plugin. Here's how I changed my POM file to configure the Eclipse project correctly:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-eclipse-plugin</artifactId>
      <configuration>
        <additionalProjectnatures>
          <projectnature>com.google.gwt.eclipse.core.gwtNature</projectnature>
        </additionalProjectnatures>
        <additionalBuildcommands>
          <buildcommand>com.google.gwt.eclipse.core.gwtProjectValidator</buildcommand>
        </additionalBuildcommands>
        <classpathContainers>
          <classpathContainer>org.eclipse.jdt.launching.JRE_CONTAINER</classpathContainer>
          <classpathContainer>com.google.gwt.eclipse.core.GWT_CONTAINER</classpathContainer>
        </classpathContainers>
        <excludes>
          <!-- These are provided by the GWT container -->
          <exclude>com.google.gwt:gwt-user</exclude>
          <exclude>com.google.gwt:gwt-dev</exclude>
        </excludes>
      </configuration>
    </plugin>
  </plugins>
</build>

If you're using GWT 1.x or earlier snapshots of GWT 2.0 you'll have to replace gwt-dev with gwt-dev-${platform}.

Now, when running mvn eclipse:eclipse, the Eclipse project will use the Google GWT plugin for the core GWT dependencies.

Building Maven artifacts for GWT 2.0.0 (trunk) and GWT Incubator

Update: Fixed svn url to GWT incubator.

Here's how I set up Hudson to run daily builds of the upcoming 2.0 version of GWT together with GWT Incubator:

I first set up a job 'GWT-2.0' to check out and build GWT itself. There are two repositories needed:

http://google-web-toolkit.googlecode.com/svn/trunk

and
http://google-web-toolkit.googlecode.com/svn/tools

Hudson then runs the following script to build GWT and deploy the maven artifacts to a local repository:

LOCAL_REPO=file:///srv/maven2
cd trunk
SVN_REV=`svn info | grep Revision | awk '{print $2}'`
GWT_VERSION=2.0.0-$SVN_REV
$ANT_HOME/bin/ant clean
$ANT_HOME/bin/ant -Dgwt.version=$GWT_VERSION

for artifact in `ls build/lib`;
do
artifact_packaging=${artifact##*.}
artifact_name=${artifact%.*}
$MAVEN_HOME/bin/mvn deploy:deploy-file -DgroupId=com.google.gwt -DartifactId=$artifact_name -Dversion=$GWT_VERSION -Dpackaging=$artifact_packaging \
-Durl=$LOCAL_REPO -DgeneratePom=true -Dfile=build/lib/$artifact
done

$MAVEN_HOME/bin/mvn deploy:deploy-file -DgroupId=com.google.gwt -DartifactId=gwt \
-Dversion=$GWT_VERSION -Dpackaging=zip -Durl=$LOCAL_REPO -DgeneratePom=true -Dfile=build/dist/gwt-$GWT_VERSION.zip

For GWT Incubator I trigger a build after each successful build of GWT. The Incubator repository is at

http://google-web-toolkit-incubator.googlecode.com/svn/trunk

After checking out, hudson runs the following script to build and deploy the Maven artifact:

LOCAL_REPO=file:///srv/maven2

export GWT_TOOLS=/home/hudson/.hudson/jobs/GWT-2.0/workspace/tools
GWT_SVN_REV=`svn info /home/hudson/.hudson/jobs/GWT-2.0/workspace/trunk/| grep \
Revision | awk '{print $2}'`
GWT_VERSION=2.0.0-$GWT_SVN_REV
export GWT_HOME=/home/hudson/.hudson/jobs/GWT-2.0/workspace/trunk/build/staging/gwt-$GWT_VERSION

cd trunk
$ANT_HOME/bin/ant -Dgwt.dev.jar=$GWT_HOME/gwt-dev.jar
$MAVEN_HOME/bin/mvn deploy:deploy-file -DgroupId=com.google.gwt -DartifactId=gwt-incubator \
-Dversion=$GWT_VERSION -Dpackaging=jar -Durl=$LOCAL_REPO -DgeneratePom=true -Dfile=build/dist/gwt-incubator.jar

Agilo for Scrum Trac plugin for Fedora

I have been looking around for open source Scrum and agile-related tools for a while, and today I set up an instance of Trac with the Agilo for SCRUM plugin from Agile42. This is an Apache v2-licensed plugin that converts your Trac-instance to a full Scrum-management tool, with Requirements, User Stories, Sprints and Backlogs (and so on). I'm happy with it so far, although I've only played with it for 30 minutes. Learning Scrum is a different story...


For those interested, I created an RPM out of it, and put it up together with the spec file on my fedorapeople account.

Wiretapping Open Translation Tools 09

Just spent 30 minutes this morning reading content from the ongoing OTT09 event in Amsterdam through my Feed reader, mainly reading the Wiki output and the twitter messages.

Creating and sharing Mock-ups

I sometimes find working within distributed teams a really tough challenge. Different time-zones, communication and language barriers. The 'disconnectedness' of distributed collaboration often ends up meaning we talk using the same terms , but have very different ideas in our minds.

So, to ease these challenges, I've started to investiage different ways in which we can improve collaboration within the projects I'm involved in, moving beyond the traditional IM/IRC, Email and phone-conferencing facilities we use every day.

When developing software, I love visual representations of ideas, such as ER diagrams, UML, and UI prototypes/mock-ups. I am a very visual thinker, and usually spend a lot of time sketching ideas on paper before implementing them in code. However, paper isn't the easiest medium for collaboration across the globe, especially when you want to mash-up and collaborate in this process. I still haven't found a good and FOSS 'sketching' tool, but must admit that I have in previous lives relied a lot on e.g. MS Visio.

Today, however, I discovered Balsamiq Mockups, a web and desktop based mockup tool based on Adobe AIR. It was easy to install on Fedora 9 (using Flash 10 and the Linux Beta of Adobe AIR). The free version won't let you save diagrams or PNG snapshots, so a lower resolution(?) screen-grab will have to do for now. It also lets you import/export diagrams as XML (even in the free version!), so it's really handy as these XML files can e.g. be stored in version control repositories and can thus easily be shared with team members. Here's a quick mock-up I did to test the application:


At some point I started missing some of the advanced layout features (e.g. modifying the values of the pie-chart), but then again, it is a mock-up and is supposed to be quick-and-sketchy!

Translation Reuse and Licensing

I've been watching with great interest the recent move within Launchpad Translations (formerly known as Rosetta, the Translation Infrastructure used by Ubuntu and others) to enforce a licensing policy on translations contributed through the web-based translation tool. Basically, from the end of this month, translators will have to either agree to publish all their translations under a BSD license, or stop using Launchpad for translations.

In the past, translations were contributed under the same license as the project itself. The reason for this new direction is to be able to legally reuse translations across project and license boundaries. Up until now, showing translation suggestions from projects which had an incompatible license to the project being translated have been a rather fuzzy area.

(This is not really a new move, as the Launchpad terms of use always granted Canonical the rights to use these translations anyway.)

I personally find it rather silly (or at least counterproductive to the goal of sharing knowledge) that resource-files such as PO files are covered by the same license as source code. What I do know is that we will start to see more and more cross-project reuse of translations, so thank you Launchpad folks for taking the first steps towards sorting out some of the legal issues!