Grails Maven Plugin

It's not clear what dependencies are pulled in when running Grails tasks from Maven. I ran into a number of problems using the Maven plugin that resulted from it pulling its dependencies, rather than the dependencies defined by my Grails application.

For instance, I was using the recently grails-1-1 beta, but the SNAPSHOT grails-maven-plugin I was using pulled in an older version of grails-bootstrap, which transitively pulled in Groovy 1.5.x. The result is running mvn grails:run-app got bizzare method missing exceptions since the old version of Groovy was loaded.

I think the best way to address this is to defer to the user's application (their Maven project's pom.xml) to define ALL needed dependencies. They would define them as "test" or "provided" dependencies as appropriate. That way I can look at the transitive dependencies of my project and know exactly what I'm pulling in. (Commands like mvn dependency:tree can be used to see this.)

There is some precedence for this approach, such as with the maven-surefire-plugin. That plugin determines what version of JUnit or TestNG to use from the consumer's project rather than linking to JUnit itself.

I'll be happy to contribute to this effort, but wanted to discuss the strategy first.

It's not quite as clear cut as this because the plugin does depend on some of the Grails artifacts, and it shouldn't really leave it the user to choose which versions of those artifacts should be used. I have tried to demarcate the dependencies required by the plugin and the build, and the those required by the application to run, so hopefully this won't be an issue. I'll see how well the current setup is working and then revisit this issue.

This won't be an issue as long as the plugin uses the same version of Grails and Groovy as the consumer. So if the plugin is always released kept in sync with Grails we'll be okay.

The alternative is to use reflection to invoke the Grails artifacts defined in the user's POM. This has the advantage of allowing a single plugin version work with multiple Grails updates, and makes it clear to the consumer exactly what is being used to build and test their project. This is the approach used by the Surefire plugin to launch unit tests with consumers' dependencies. [1]

[1]
http://maven.apache.org/plugins/maven-surefire-plugin/

The plugin no longer depends directly on Groovy, so that at least should no longer be a problem. On the Grails front, that's an interesting idea. Since the plugin depends directly on the classes in the "grails-bootstrap" artifact, I'm not sure how much scope there is to decouple it from a particular version. For example, you couldn't use it with Grails 1.0.x. That said, after 1.1 the classes in "grails-bootstrap" are unlikely to change an awful lot (at least I hope not) so perhaps we could do it that way.

I'll look into doing it for 1.1.

There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3

for 1.2 final only issues considered blocking will now be fixed

I have fixed this in a roundabout fashion in our own environment by downloading the plugin, removing the content of dependencies.groovy and making a composite (a pom only project) that includes the plugin and dependencies. The maven grails plugin seems to treat all maven dependencies resolved via a grails-plugin/zip as being a grails-plugin (instead of just the plugin itself). This has of course meant another plugin that just exposes the resource types of grails-plugin and grails-app. I'll be fixing the latter problem in our copy of the plugin.