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!

The acrobatics of community-based localisation

Michael Kaplan has an interesting post discussing the perceived 'failure' of the Swahili-language version of Microsoft Office which was released in 2003. This lesson clearly shows the benefits of some level of community-input in the localisation process. I found this quote from Kaplan rather interesting:

...the job of the localizer is as important as it ever was, if not moreso -- something that can also speak against complete "community" reliance rather on making sure competent people who understand the source and target markets and can translate between them are present in sufficient numbers to do what it may well turn out to be that no educational or governmental entity, what no group of people can actually accomplish successfully on their own.

The success of community-based localisation is indeed dependent on the ability of the community to transfer the ideas and concepts present in the source-language into their own culture and language. Well, that's no different than any other community-based project, and perhaps shows some of the acrobatics involved when commercial vendors attempt to include social translation as part of their localisation workflow.

Now, if only I'd been more interested in learning languages growing up... I spend most of my childhood from age 6 to 12 in Luoland in Kenya, and spoke solid African English with a mix of Swahili, Luo and Norwegian words. Imagine that (if you can)!