Dissecting Grails for Maven building

Show me your war, and I will tell you how it does!

Upgrading a Java project from a legacy buildsystem to Maven involves lots of reverse engineering to understand how the application works. Starting to investigate a project by its deliverables is often the most easy, taking a working application and picking away piece by piece, like dissecting a frog, to see if it still works after some abuse and halfchanced guesswork.

I started by grails create-app'ing a simple book tutorial grails app, and grails war'ing it. The contents of the war were extracted into src/main/webapp of a maven demo project, supported by groovy-all, GMaven (Groovy Maven plugin) and Maven Jetty plugin.

What can be moved out of the WEB-INF structure is

• *.properties and *.xml files, located in WEB-INF/classes, into src/main/resources


• the Java code, if present, can also easily be moved into src/main/java IF they do not rely on the domain classes


• groovy code which is not decorated by GORM, grails scaffolding and other Grails magic

What is currently problematic to extract is the domain, and controller classes, as they are decoreted by Grails Voodoo Magic I have still to investigate how works. Also, the GMaven compiler has problems tackling groovy files such as DataSource, Config and (Spring) resources, because they are DSL Groovy script files and not classes.
Making grails plugins can also prove to be a challenge to support. Accepting the Grails folder structure in the plugins is one thing, but the plugins are also programmed to add changes to the main project if called upon.
The Octo Maven plugin, for building Grails projects in Maven, is one interesting way of dealing with the problem, though I believe that the people who prefer Maven for building will not be satisfied by wrapping ant magic in Maven.

I will propably look further into the matter of the Groovy/GORM/Grails decoration and post whatever I find, but please give me a holler if this topic is interesting.