Gaedo, tapestry and mutual injection: where Proxies solve the egg and chicken problem

I was thinking about how to integrate the gaedo library with our tapestry project. Gaedo is a persistance library providing dynamic finders.
To use gaedo properly with tapestry my first guess was to define a module (in tapestry terms) providing the required ServiceRepository which is the main entry point for gaedo. The GaedoModule class defines that binding for this interface using a build() method:
With the right entry com.dooapp.gaedo.tapestry.GaedoModule: com.dooapp.gaedo.tapestry.GaedoModule in the Manifest.mf file, dropping the jar of the gaedo-tapestry module in our tapestry application classpath is enough to get our module automatically loaded.
As you can see in the build method, we expect a Collection<FinderCrudService> configuration to configure the ServiceRepository properly. This parameter can be provided through the tapestry mechanism for service configuration. So in the AppModule of our tapesty application we just need to define a method call contributeServiceRepository to provide the required configuration to our ServiceRepository.
You might have noticed that we get the ServiceRepository injected in this method. Weird? Who will be instanciated first? The ServiceRepostiory that requires the collection of FinderCrudService to be fully configured or the FinderCurdService which needs itself the ServiceRepostory to be instanciated?

I was thinking some hours about how to solve this problem, trying to remove some dependencies when I stumbled upon the documentation about mutually dependent services injection with the tapestry IoC framework. And the conclusion is: it *just* works! I had nothing to do! This mutual injection just perfectly works out of box! Amazing! The big point is that the tapestry IoC framework is working with Proxies to instantiate objects, and that's the key of this egg and chicken mistery. Both service can be instantiated in any order, you don't need to care about it. It will work.

Synchronize maven and gae application version

We are currently developing a maven project deployed on google appengine.Maven manages a version property in its pom.xml:

When we release the project with maven (mvn release:prepare and mvn release:perform), this version number gets automatically increased to the next development version, for example from 0.0.1-SNAPSHOT to 0.0.2-SNAPSHOT.
The main problem is that google app engine uses another version descriptor in the appengine-web.xml file that is independent from the first one:

It would be great to get those to versions number synchronized! Here is a solution how to get it working:

  • Define a tiny groovy script, let's say utils.groovy, that will define a property defining the gae version. The problem is that we can't use the maven version directly since gae does not accept '.' and '-SNAPSHOT' in it's version. So this script will map the gae version to the maven version in that way:  X.Y.Z(-SNAPSHOT) -> X-Y-Z . Of course we will lose the SNAPSHOT information, but this is not really relevant in gae terms. Your application will be deployed at X-Y-Z.latest.myproject-site.appspot.com.

  • Attach the execution of the groovy script to the maven validate phase adding this to the pom.xml

  • This will define a maven property named gaeversion that you can use in your appengine-web.xml file

  • And finally tell to maven to filter our appengine-web.xml resource!

John hudson and continuous integration

Capture

We were thinking about a solution to keep up our google chatroom up even we all get disconnected. We were thinking about a bot when I remembered about a jabber plugin for hudson - actually, if we use a bot on the chatroom, why not hudson?

So we installed the plugin and after some configuration (make sure you configured it both in the global hudson configuration and in the project configuration, since it is not activated by default), we finally welcomed John Hudson as new colleague in our chatroom. This way we get informed of various events (build start, build failed,...fully configurable) directly in the chatroom.
And you know the best? We can even control hudson from jabber using simple commands such as !build myproject 
Simple and amazing. Continuous integration is great!