(Quick Reference)

3 Maven integration

One of the best things that sprung from Maven was a standard way to provide Java dependencies to projects via HTTP-based repositories. Not only do we now have the Maven Central repository, but it's almost trivial to set up your own company-wide Maven-compatible repositories using tools like Nexus or Artifactory. Following on from the Maven Publisher plugin, the Release plugin provides everything you need to easily and effectively deploy your project artifacts to such repositories.

Before we look at deployment to one of these remote repositories, let's look at another aspect of Maven: installing artifacts into the local Maven cache.

3.1 The local Maven cache

When Maven builds a project, it first looks for the project's dependencies in the local Maven cache (by default $HOME/.m2/repository). Only if a dependency is not in the cache does Maven pull it from the appropriate remote repository. This makes testing pretty easy: simply install your own version of the artifact into the Maven cache and that's the one that Maven will use. You don't have to deploy a development version of an artifact to a remote repository just to test it.

This approach doesn't only work for Maven. Grails can also pull artifacts from the Maven cache if you add the following entry to your project's BuildConfig.groovy file:

So how do you get your plugins or WAR files into the Maven cache? With the maven-install command:

grails maven-install

That's it! You can then test your new artifact locally. If you want, you can change where your artifacts are installed by adding the following configuration option to either BuildConfig.groovy or settings.groovy:

By adding this option to settings.groovy it will apply to every project that doesn't override it, so be careful!

Installing artifacts to the local Maven cache is trivial, so what about remote deployment?

3.2 Deployment to remote repositories

TBC See maven-deploy for the moment.