Production Groovy Part I: The trouble with Grape
Like Perl, Groovy's utility is most evident while leveraging the work of others. In Groovy 1.7, Grape makes doing so intuitive with the addition of annotations on import statements:
@Grab( group = 'com.sun.jersey', module='jersey-core', version = '1.1.2-ea' )
@Grab( group = 'com.sun.jersey', module='jersey-server', version = '1.1.2-ea' )
The trouble with Grape is that by default it resolves dependencies by contacting or attempting to contact certain Maven2 repositories. Now, this isn't a problem if you're a web startup looking to bring a product to market as quickly and cheaply as possible. But it is a problem if you're looking to start deploying Groovy to a secure production environment. Fortunately, Groovy's close coupling with Java provides a clean and elegant solution.
The key is that Maven2 remote repository caching and local repository hosting has been made easy by Artifactory. It can be configured to dynamically dial out and cache artifacts on demand from remote repositories. It can also more simply be used to manually manage artifact deployment. Thus provinding both flexibility and control.
In order to take advantage of Artifactory you'll want to modify the default Grape/Ivy configuration so it points to your internal Artifactory repository by default. The bad news is that you'll need to modify the an xml file and rebuild the the jar. The good news is that the groovy source itself uses Ivy so modifying the xml and building Groovy is really easy.
Simply download the latest Groovy source zip. Then modify '/src/main/groovy/grape/defaultGrapeConfig.xml'. You can then build yourselve a new zip distribution by running 'ant createJars -DskipTests=true'.
Skipping the tests is optional, of course.
Thats it. Once you explore Artifactory a bit you'll discover that it can provide as little or as much control of the artifacts available to Grape as you desire.