Monthly Archives: November 2013

Grails 1.3.x and plugin dependency name conflict resolution

I got this tip off of @rfletcherEW

Grails 1.3.x the plugin fails to install

Plugin something-0.2 installed

[delete] Deleting directory /Users/you/.grails/1.3.9/projects/myProject/resources

Plugin /Users/you/.ivy2/cache/org.somethingGroup/plugin/jars/something-0.2.jar is not a valid Grails plugin. No plugin.xml descriptor found!

The reason

You want to use plugin something-0.2 and it contains jar something-0.2.jar which is the same name as the plugin.  The dependency management system cannot cope with this in 1.3.x  This has been fixed in 2.0 but for people running 1.3.x it still causes issues.

The Work Around

It is a bit dirty it just involves creating a new plugin with a different name

  1. Clone the project.  Most of them are on github anyway.
  2. Get the right branch or version from the commit logs.
  3. Change the name of the  class SomethingGrailsPlugin to be different from its required dependencies.  E.G: class SomethingFishGrailsPlugin
  4. Compile the plugin.
  5. Package the plugin
  6. Deploy the plugin into your maven mirror.  If you don’t no one can build your project as they will not find your plugin, and if you delete your ivy cache you lose all your hard work.
  7. Push the source into your source control.
  8. Document what you have done to your project
  9. Push to migrate from 1.3.x as soon as possible to 2.x and remove your plugin and use the full version of the plugin again.
  10. If you need to upgrade your plugin you have to do all those steps again.


Gradle could not resolve commons-logging

My gradle build would fail for an unexpected reason. This could be any common jar but one I know would be in the maven central repo without any problems.

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration ‘:sham-core:testCompile’.
> Could not download artifact ‘commons-logging:commons-logging:1.1.1@jar’
> Artifact ‘commons-logging:commons-logging:1.1.1@jar’ not found.

Problem with repositories

My build.gradle had the following for resolving repositories

buildscript {
repositories {

Turns out that my maven local had some sort of problem with gradle when the jar is not present in the maven local.

Options to fix this

  1. remove mavenLocal() from your gradle build script
  2. Move the maven local repo mv ~/.m2/repository ~/m2/repo-tmp . Build the project and move it back mv ~/m2/repo-tmp ~/.m2/repository
  3. Delete the maven local repo rm -rf ~/.m2/repository/ .

I do not use much maven so I just did 3.

Gradle and Could not initialize class YYYYYY

In Gradle I got stumped by this even though class YYYYYY was on the classpath.
java.lang.NoClassDefFoundError: Could not initialize class YYYYYY

I put a try catch block around the code that was failing. This gave me a more direct error than before.
It turned out that I had XML reading error where a class was trying to read a file that was not present on the classpath

The class was present but the initialization failed, check your setup.

Gradle groovy compile and out of memory error

Today was my first real day with Gradle.

I struggled for hours trying to get the groovy compile process to have enough memory to compile my code and not fall over with out of memory exceptions. This is what I would usually get.

Started Gradle compiler daemon with fork options DaemonForkOptions{minHeapSize=null, maxHeapSize=null, jvmArgs=[], classpath=[/Users/muz/.gvm/grails/1.3.9/lib/groovy-all-1.7.8.jar, /Users/muz/.gvm/gradle/1.8/lib/ant-1.9.2.jar, /Users/muz/.gvm/gradle/1.8/lib/ant-launcher-1.9.2.jar]}.

Executing org.gradle.api.internal.tasks.compile.ApiGroovyCompiler@e4865ce in compiler daemon.

Exception executing org.gradle.api.internal.tasks.compile.ApiGroovyCompiler@e4865ce in compiler daemon: java.lang.OutOfMemoryError: Java heap space.

Things that did not work

Continue reading