The big news of this week was the 2012 Groovy & Grails Exchange in London. Lots of great content this year, and attendance was up 40% from last year. It’s always a great conference thanks to the fine folks at Skills Matter who run the conference and many other events throughout the year. They’re great about getting videos of the talks online quickly and you can check them out at the conference schedule – click through each talk to the full description. There was a lot of Twitter activity – search on the #ggx hashtag. Here are several of the more interesting ones, including several links to presentations and sample code:

• @skillsmatter: Enjoying this year’s #groovy & #grails eXchange? Get your early-bird ticket for #ggx 2013 @skillsmatter here! http://t.co/5UszLwwy
• @marcinerdmann: room is completely packed for @rfletcherEW ‘s Grails for hipsters talk #ggx http://t.co/Zpw4rKFG
• @marcinerdmann: love how passionate @hans_d is when he’s talking about #gradle, great tool, great presentation #ggx
• @rfletcherEW: Code for the demo app from my #ggx “Grails for hipsters” talk is available at http://t.co/AnNxuwdU
• @rfletcherEW: Slide from my #ggx “Grails for hipsters” talk are available at http://t.co/nLRnwWQr
• @rfletcherEW: #ggx panel kicking off http://t.co/S8gkCYA1
• @rfletcherEW: A particularly flattering photo of @smaldini @wangjammer5 & antony at #ggx http://t.co/BUJFSxxG
• @rfletcherEW: Code for my #Spock demo at #ggx is available here: http://t.co/7Yjvma4A look at the different branches for starting points / completed
• @rfletcherEW: #ggx @smaldini sporting a nice hipster hat as he starts his Reactive Grails tal @ The Skills Matter eXchange http://t.co/QIYuQxsj
• @aalmiray: code for “Griffon Jumpstart” @ #ggx is available at http://t.co/vaX1lSGP
• @aalmiray: . @burtbeckwith created his “Grails Security” slides with #griffon sweet! #ggx
• @CedricChampeau: Slides from my #ggx talk “Type checking your DSLs” are here: http://t.co/yGAI6bOT code is here: http://t.co/LdZYBlrm #groovy #dsl
• @glaforge: We now have a #groovy developers community on #google+ if you want to chat and exchange news and more. https://t.co/NOti9r60
• @marcoVermeulen: Grailsx attendance grows by 40% from last year. #ggx
• @bobbywarner: All the slides and demos for my two #ggx talks are located here: https://t.co/daL6KXNw #grails #groovy
• @smaldini: my slides about #grails #platformcore events #ggx http://t.co/jXPKc2CW
• @smaldini: Take the #grails hipster bus – use #platformcore events on http://t.co/FFU84N45 http://t.co/CyG1yB30
• @pidster: My #ggx 2012# vertx deck on @slideshare http://t.co/opTLqP1K
• @pidster: mod-thymeleaf – the example project shown in my #vertx talk at #ggx earlier today: https://t.co/C8CfKhiD <- lots of goodies
• @wangjammer5: Uploaded the slides for my #grails Platform Core talk: https://t.co/APP4CH2h
• @wangjammer5: Uploaded slides for my #grails Platform UI talk #ggx https://t.co/nOYWiJ2I
• @corinnekrych: Slide for Building DSL with User Interaction at http://t.co/xNg88vxG #ggx
• @glaforge: Slides and video of my #groovy 2.0 and beyond presentation at #ggX are available: http://t.co/4Dk8Yu2V and http://t.co/NkdLjEN9
• @burtbeckwith: Slides for my Using Spring in #Grails talk at #ggx and #s2gx http://t.co/nAJWgodL
• @burtbeckwith: Slides from my #ggx talk on #Grails security http://t.co/hKMLEvMw

In addition, Grails 2.1.2 was released with some fixes for the 2.1.x line (note that the distribution is now ~120MB since it includes source and Javadoc), and Grails 2.2.0 RC4 was released. This will be the final RC release before the 2.2 GA release and it includes Groovy 2.0, so you should definitely check it out and start looking now at upgrading.

The Spring Loaded JVM agent that we use in Grails 2.0+ for code reloading was open-sourced this week.

The folks at Canoo released Open Dolphin which integrates Enterprise applications with Java Desktop applications.

I released a new plugin, the tcpmon plugin. It provides the TCPMon proxy tool which can help with debugging web services and rest APIs.

If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.

Translations of this post:

• Grails每周观察
• Este artigo em Português
• Traduzione Italiana
• 今週のGrails日本語版

 Miscellaneous Items
 Plugins
 Interesting Tweets
 Jobs
 User groups and Conferences

The big news of this week was the 2012 Groovy & Grails Exchange in London. Lots of great content this year, and attendance was up 40% from last year. It’s...

If you need a jar library in a Grails plugin, the best approach is to add a dependency in BuildConfig.groovy from a Maven repository so you (and your users) only download it once and use it for each project that needs it. This works well as long as the jar is in Maven Central or some other repo, but some smaller projects don’t publish to Maven repos, so sometimes you are stuck with jar files in the lib directory. Using dependency management is convenient, especially since you can override the version in the application later if a newer jar version is released.

The standard syntax is simple, for example

dependencies {
   compile 'com.atomikos:transactions-jms:3.8.0'
}

This is great, but due to the way Maven works this can result in far more than just that one jar file since all of its dependencies and transitive dependencies will also be downloaded and added to the project’s classpath. That’s what you want most of the time, but often I’ve found that there are unneccessary depdendencies, or dependencies that are already provided by Grails or another plugin but with a different version. So I tend to list out all of the dependencies that I actually want to end up with, adding the necessary exclusions to the dependency declarations. For example here are the two that the spring-security-core plugin defines:

compile('org.springframework.security:spring-security-core:3.0.7.RELEASE') {
   excludes 'spring-expression', 'spring-core', 'spring-context', 'spring-tx',
            'spring-aop', 'spring-jdbc', 'spring-web', 'spring-test', 'aspectjrt',
            'aspectjweaver', 'cglib-nodep', 'ehcache', 'commons-collections',
            'hsqldb', 'jsr250-api', 'log4j', 'junit', 'mockito-core', 'jmock-junit4'
}

compile('org.springframework.security:spring-security-web:3.0.7.RELEASE') {
   excludes 'spring-security-core', 'spring-web', 'spring-jdbc', 'spring-test',
            'commons-codec', 'hsqldb', 'servlet-api', 'junit', 'mockito-core', 'jmock-junit4'
}

I could have cheated and just used transitive = false:

compile('org.springframework.security:spring-security-core:3.0.7.RELEASE') {
   transitive = false
}

compile('org.springframework.security:spring-security-web:3.0.7.RELEASE') {
   transitive = false
}

but this is really only appropriate for applications; in plugins it’s better to avoid this so the pom files are correct.

This usually isn’t that hard to do; it’s just a matter of reading pom.xml files and copy/pasting the relevant bits. But it can be tedious and I realized recently that this was an excellent use case for a Groovy script.

If you’ve installed the release plugin (it should be there since it’s added to the plugin’s BuildConfig.groovy by default) then you can run the generate-pom and it will generate target/pom.xml.

The process that I use is iterative. The first step is to use the transitive = false attribute that I said not to use earlier. This will generate a pom.xml with all of the dependencies and transitive dependencies enumerated for you for each of your specified dependencies. Then run this script in a Grails or Groovy console and it will build the proper syntax for each declaration:

String xml = new File('/path/to/pom.xml').text
for (dependency in new XmlSlurper().parseText(xml).dependencies.dependency) {
   String scope = dependency.scope ?: 'compile'
   Set exclusions = []
   for (exclusion in dependency.exclusions.exclusion) {
      String groupId = exclusion.groupId
      String artifactId = exclusion.artifactId

      if ( (groupId == 'xml-apis' && artifactId == 'xml-apis') ||
           (groupId == 'xml-apis' && artifactId == 'xmlParserAPIs') ||
           (groupId == 'xerces' && artifactId == 'xmlParserAPIs') ) {
         continue
      }

      exclusions << "'$artifactId'"
   }

   String combined = dependency.groupId.text() + ':' +
       dependency.artifactId.text() + ':' +
       dependency.version.text()
   if (exclusions) {
      println "\t$scope('$combined') {"
      println "\t\texcludes ${exclusions.sort().join(', ')}"
      println "\t}\n"
   }
   else {
      println "\t$scope '$combined'\n"
   }
}

Replace transitive = false with the output from the script. If this is sufficient then you’re done, but if you’ve excluded a jar file that you will need, then add it as an explicit dependency with transitive = false and run the script again. Repeat the process until all of the important jar files are listed, and all of their dependencies are properly excluded. Keep in mind that you don’t have to list everything, just what you need to get your plugin working. If a user needs another related jar that you excluded, it can always be added to the application’s BuildConfig.groovy.

For a more extensive example, see the db-reverse-engineer plugin’s BuildConfig.groovy. I could have just defined a dependency for the Hibernate Tools jar, but to do it correctly I ended up with six dependency declarations.

If you need a jar library in a Grails plugin, the best approach is to add a dependency in BuildConfig.groovy from a Maven repository so you (and your users) only...