A search for meaning in software and life
RSS icon Email icon Home icon
  • Building a Grails project with Gradle

    Posted on February 5th, 2010 Peter 46 comments

    Earlier this week, I attended Hans Dockter’s first ever Gradle course. Everything seemed to click into place and it inspired me to have another crack at writing a Gradle plugin for building Grails projects. A lot of the hard work had already been done to get the Maven plugin working reasonably well, so all I had to do was make use of the helper classes that already existed for bootstrapping the Grails build system.

    So how do you use it? Simple. Here’s a basic Gradle build file (build.gradle) that you can put in the root of your Grails project:

    buildscript {
        repositories {
            mavenCentral()
            mavenRepo urls: 'http://snapshots.repository.codehaus.org'
            mavenRepo urls: 'http://download.java.net/maven/2/'
        }
    
        dependencies {
            classpath "org.grails:grails-gradle-plugin:1.0-SNAPSHOT"
        }
    }
    
    apply id: "grails"
    
    repositories {
        mavenCentral()
        flatDir dirs: "lib"
    }
    
    configurations {
        compile.exclude module: "commons-logging"
    }
    
    dependencies {
        compile "org.grails:grails-crud:1.2.0",
                "org.grails:grails-gorm:1.2.0",
                "org.apache.httpcomponents:httpclient:4.0",
                "org.apache.httpcomponents:httpmime:4.0",
                ":apache-solr-solrj:1.4:dev",
                ":pgptools:0.1"
    
        // Required by the Joda Time plugin.
        compile "org.springframework:spring-web:3.0.0.RELEASE"
        compile "org.springframework:spring-webmvc:3.0.0.RELEASE"
    
        // Required by the JMS plugin.
        compile "org.springframework:spring-jms:3.0.0.RELEASE"
    
        runtime "org.slf4j:slf4j-log4j12:1.5.5",
                "hsqldb:hsqldb:1.8.0.5",
                "postgresql:postgresql:8.3-603.jdbc3",
                "org.bouncycastle:bcpg-jdk15:1.44",
                "net.sf.ehcache:ehcache-core:1.7.1"
    }
    

    Unbelievably, that’s it! You can now execute any of the Grails commands via Gradle like so:

    gradle compile
    gradle create-domain-class -Pargs=org.example.Book
    gradle run-app
    gradle run-app -Pargs=--https -Penv=prod
    gradle create-gwt-action -Pargs="--shared-pkg=client org.example cmd ListBooks"
    

    The -Pargs option allows you to pass any arguments you want to the corresponding Grails command, while -Penv allows you to override the default environment. In case you’re wondering, the -P option allows you configure project properties. args and env are simply two that are understood by the Grails plugin.

    So what’s happening in this build file? First of all, we use the buildscript {} section to configure the plugin as a dependency of the script. Once the plugin is on the classpath, we can apply it to our build via apply id: 'grails'. Alternatively, you could download the plugin JAR file and put it into $GRADLE_HOME/lib.

    The rest of the build file is concerned with setting up the dependencies for our Grails project. Quite a few are declared in this example, but the only requirement is that you declare dependencies on at least one Grails module, a logging implementation, and the JDBC driver(s) for whatever database(s) you’re using. If you’re using the Hibernate second-level cache, you should also include EhCache or OSCache.

    The true beauty of this plugin is that *all* the Grails commands are available to you, including those provided by plugins. This is far better than the Maven plugin, which has a set of hard-coded goals for the most common Grails commands and a generic exec goal for executing arbitrary Grails commands. I haven’t tested all of the commands, so feel free to report any problems.

    The code for the plugin can be found on GitHub. I think you’ll be surprised at how little code there is. In fact, there are only two files: build.gradle in the root of the project, and GrailsPlugin.groovy under src/groovy. I definitely recommend taking a look at the plugin file to see how Gradle’s dynamic tasks made it so easy to support all the Grails commands.

    Give it a go and see what you think!

    Update First off, the plugin currently only works with Grails 1.2.0+ and Gradle 0.9 snapshots. Second, I’m aware that the build script doesn’t work at the moment. Unfortunately, there appears to be a Gradle bug preventing the fixed build script from working. Stay tuned.

    Update 2 My bad. The version of mavenRepo that takes more than one repository URL expects the first one to contain the POM, while the other ones are for getting hold of the JARs. I have corrected the example build so that it has separate mavenRepo lines for the Codehaus Snapshots repository (for the plugin) and the java.net repository (for GParallelizer),

    Update 3 I have uploaded a new version of the plugin that allows you to start from scratch. Create a new directory for your Grails project and add the following build.gradle file to it:

    buildscript {
        repositories {
            mavenCentral()
            mavenRepo urls: 'http://snapshots.repository.codehaus.org'
            mavenRepo urls: 'http://download.java.net/maven/2/'
        }
    
        dependencies {
            classpath "org.grails:grails-gradle-plugin:1.0-SNAPSHOT"
        }
    }
    
    apply id: "grails"
    
    version = "1.0-SNAPSHOT"
    
    repositories {
        mavenCentral()
        flatDir dirs: "lib"
    }
    
    configurations {
        compile.exclude module: "commons-logging"
    }
    
    dependencies {
        compile "org.grails:grails-crud:1.2.0",
                "org.grails:grails-gorm:1.2.0"
    
        runtime "org.slf4j:slf4j-log4j12:1.5.5",
                "hsqldb:hsqldb:1.8.0.5",
                "net.sf.ehcache:ehcache-core:1.7.1"
    }
    

    From the new directory, run gradle init and a fresh Grails project will be created for you.

     

    46 responses to “Building a Grails project with Gradle”

    1. Just what I was looking for!
      But I cannot get it to work on my Grails 1.2.1 project.

      * What went wrong:
      Could not resolve all dependencies for configuration ‘classpath’:
      – unresolved dependency: org.grails#grails-bootstrap;1.2.0: not found

    2. This is great news. I’ve been hacking together a solution by getting Gradle to use the ant.exec task but it’s not exactly fast.

      A couple of questions…

      1. Can I have a multimodule project (e.g. a plugin with stuff under test/projects/xxx) and test everything with a single command at the root?

      2. I notice you’re pulling in some joda-time plugin dependencies, is that always necessary or only because joda-time isn’t yet using the Grails dependency DSL?

    3. Also, I’m seeing the same problem as Goran when I try using the script.

    4. Sorry. I appear to have been a victim of caching. In the buildscript section, you can try:

          repositories {
              mavenCentral()
              mavenRepo urls: 'http://snapshots.repository.codehaus.org'
          }
      

      This throws an exception when you first build the project, because it can’t get hold of GParallelizer. However, you need to do this first step.

      Then you can add an extra Maven repository to complete the build:

      
      
          repositories {
              mavenCentral()
              mavenRepo urls: [ 'http://snapshots.repository.codehaus.org', 'http://download.java.net/maven/2/' ]
          }
      

      Unfortunately, there appears to be a bug in the 0.9 SNAPSHOT which means you can’t use the second syntax the first time you build the project.

      Note that once you have one project building, you won’t run into problems with other projects because the required dependencies will already be in Gradle’s cache.

    5. @Rob
      #1 I don’t see why not.

      #2 The Gradle plugin tells Grails that it’s managing the project dependencies, so Grails doesn’t do any of the dependency management itself. I did, however, think that it added plugin dependencies to the classpath regardless, but that doesn’t seem to be the case. I need to look into it.

    6. Hmm. I’m getting closer but now I’m blocked by the fact that GrailsPlugin.groovy specifically references “tools.jar” in the JDK home… I’m on a Mac… which doesn’t have a tools.jar in it’s crazy Apple JDK

    7. Thanks Peter, I got it working after a few changes.

      1. Changed repository config as you described above.
      2. Upgraded Gradle from 0.8 to 0.9-SNAPSHOT
      3. Changed grails (crud+gorm) compile dependencies from 1.2.0 to 1.2.1
      4. Removed compile dependencies apache-solr-solrj and pgptools.

      Now my grails 1.2.1 project compiles!

      Great stuff, I will continue to play with it later this weekend.

    8. Hi Peter,

      we’re currently using the grails-maven-plugin to build our Grails apps. This road appears to be quite bumpy, but eventually succeeds to integrate nicely within out software building processes.

      As we haven’t used Gradle before, the terse set of build statements appears to be rather intriguing, but we are uncertain, whether it will completely cover an application life cycle for production purposes.

      Can I have some sort of central parent the build inherits from in order to avoid manually amending or updating it (e.g. company repository servers, or changed dependencies after a Grails version change)? Shouldn’t all the Grails dependencies be defined in some sort of template-link specific for a particular Grails version?

      Would it be possible to extract plugin dependencies from the application itself (i.e. as defined within application.properties)?

      Can the Build be used to deploy the Grails war to an artifact repository? And if yes, does it support both snapshots releases and tagging final release sources?

      Can Hudson pick up the dependencies and schedule another Snapshot build when one of the dependencies changes?

      Sorry for asking suspectedly dumb questions,
      Reiner

    9. As we haven’t used Gradle before, the terse set of build statements appears to be rather intriguing, but we are uncertain, whether it will completely cover an application life cycle for production purposes.

      This is precisely what Gradle is geared towards: automating the *whole* of your build, including release and deployment. It may not have all the plugins that Maven has, but it’s far easier to create your own custom tasks to do specialist work.

      Can I have some sort of central parent the build inherits from in order to avoid manually amending or updating it (e.g. company repository servers, or changed dependencies after a Grails version change)? Shouldn’t all the Grails dependencies be defined in some sort of template-link specific for a particular Grails version?

      Here’s an example parent:

        subprojects {
            // Configure the Grails version for all projects.
            grailsVersion = "1.2.0"
      
            // All projects use the company repository.
            repositories {
                mavenRepo urls: 'http://company/maven2/'
            }
      
            // Set common dependencies used by all projects.
            dependencies {
                compile "commons-lang:commons-lang:2.4"
                runtime "net.sf.ehcache:ehcache-core:1.7.1"
            }
        }
      

      You can even restrict settings to a sub-set of the sub-projects and have multiple subprojects sections. It really is very flexible.

      Would it be possible to extract plugin dependencies from the application itself (i.e. as defined within application.properties)?

      There is a hack in the current Maven Grails plugin that allows you to define plugins as dependencies in your POM, but it’s not much used or tested because you have to manually package up the plugins you use and deploy them to a Maven repository. I think it’s definitely worth waiting for Grails 1.3, which will install plugins from Maven 2 repositories.

      Can the Build be used to deploy the Grails war to an artifact repository? And if yes, does it support both snapshots releases and tagging final release sources?

      The Gradle Grails plugin doesn’t support this directly, but it wouldn’t be too much work to add your own custom task for this. Ideally, this plugin could re-use some parts of the Java plugin, which definitely has support for what you need. Take a look at the build file for the plugin to see how you can configure the uploadArchives task.

      Can Hudson pick up the dependencies and schedule another Snapshot build when one of the dependencies changes?

      I don’t know, sorry. I can find out, but I’d try asking on the Gradle or Hudson mailing lists first.

      Hope that helps,

      Peter

    10. Note the maven publisher plugin which I wrote works with Grails 1.2 and allows you to publish Grails war files or Grails plugin zips to a Maven repository:

      http://grails.org/plugin/maven-publisher

    11. I get “Could not find method apply() for arguments [{id=grails}]“.

    12. @Dierk That means you’re probably not using a recent enough 0.9 SNAPSHOT. I may switch to using usePlugin(), but I was indoctrinated to the latest syntax by Hans :) I’d almost got the plugin working with Grails 1.1.x too, but ran into class loader issues.

    13. Thank you Peter,

      for your detailed reply (very visually appealing as well).

      I’ll definitely have a look into Gradle now and then try to port one of our real-life Grails projects from Maven to Gradle (a true contract-first SOAP-WS using JAX-WS RI with a home-grown interface to Grails services depending on two other separate Maven-projects for the wsimport and annotated Hibernate POJOs revenged by Hibernate Tools from an all legacy DB).

      Regards,
      Reiner

    14. oops, sorry. Thanks for the clarification!

    15. @Peter – So, based on your comment from Feb 9, am I to understand that this plugin will only work with grails 1.2.x? We’re running 1.1.2; I’ve changed the references on the grails-crud and grails-gorm deps to reference our version, but I see a compiler failure:

      Cause: java.lang.NoSuchMethodException: grails.util.BuildSettings.setDependenciesExternallyConfigured(boolean)

      This method exists in 1.2.x but not in 1.1.x, so it seems that the plugin is still referencing the newer version. Is there something else I can change to find the correct version? Thanks for putting this together!

    16. @Bryan I’ve just uploaded a new snapshot of the plugin that should work with Grails 1.1.x.

    17. How can I simulate or use a scope like maven provided scope for a dependency?

    18. @André You first need to define a new configuration (a named set of dependencies) like so:

      configurations {
          provided { transitive = false }
      }
      

      In this particular case, Gradle won’t resolve transitive dependencies for any of the entries in provided, which is typically what you want. You then need to add dependencies to the configuration:

      dependencies {
          compile ...
          provided "javax.servlet:servlet-api:2.5", ...
      }
      

      The last step is to put the provided dependencies on the compiler’s classpath:

      sourceSets.main.compileClasspath += configurations.provided
      

      An alternative approach is to make provided extend compile:

      configurations {
          provided {
              extendsFrom compile
              transitive = false
          }
      }
      
      dependencies {
          provided ...
      }
      
      sourceSets.main.compileClasspath = configurations.provided
      

      In this scenario, we replace the existing compilation classpath with the provided dependencies, which also include the compile ones because of the extendFrom.

      That said, I believe that Gradle will support provided out of the box by the time it reaches 1.0.

    19. Peter, AWESOME!

      It’s been a while and it seems the current gradle 0.9 snapshot or release doesn’t work with the build.gradle anymore.

      I am having trouble getting things going. Maybe you could give some advice.

      When I run gradle init with the build file as is, I get:
      Cause: No such property: id for class: org.gradle.api.internal.plugins.DefaultObjectConfigurationAction

      Seems right so I switch to apply plugin, that leaves me with:
      Cause: org.grails.gradle.plugin.GrailsPlugin.apply(Ljava/lang/Object;)V

      I have a multi module project demo I am working on and have gotten it close to where it tells me:
      FAILURE: Could not determine which tasks to execute.

      Any advice on how I can get this going with the more recent 0.9-Preview?

    20. Figured it out. Looks like they changed the Plugin interface from void use(T) to void apply(T). Also had to add project.task(["overwrite":true], “test”) to both test and assemble.

    21. I thought that they were going to simply deprecate use() rather than drop it completely. Oh well. Thanks for the solution to the other issue too.

    22. I seem to be missing something with gradle… an example of how to get it to monitor trunk in SVN for changes. Do I have to use MVN or ant and do this? Then layer gradle on top?

      BTW thanks for getting a starting point out in the wild here. I had written gradle off until I saw this post.

    23. Helmut Tammen

      Hi Peter,

      did you change the plugin according to Ben´s suggestions. I´m running into the same problem:

      Cause: org.grails.gradle.plugin.GrailsPlugin.apply(Ljava/lang/Object;)V

      The last version of your plugin I´ve found in http://snapshots.repository.codehaus.org is from Feb. 16 th, 2010. So I guess that you didn´t correct the plugin?

    24. Helmut Tammen

      I detected another issue that only appears when using the Grails plugin (does not appear with Groovy or Java plugin).

      When defining a new task in the build script like
      task doit << {
      println "ready"
      }

      I get the following runtime error:
      Cause: Cannot add task ':doit' as a task with that name already exists.

      If I use this it works:
      task doit(overwrite: true) << {
      println "ready"
      }

    25. @Helmut Thanks for the report. I have Ben’s changes incorporated locally now, but I still need to resolve this “task with that name already exists” error. Hopefully one of the Gradle team will be able to help out. Once that’s fixed, I’ll re-release the plugin, probably as version 1.0.

    26. OK, I’ve released a new 1.0-SNAPSHOT. If there aren’t any reports within a couple of weeks, I’ll release as 1.0.

    27. Peter, I have not completed full testing yet but I have found with gradle 0.9 preview 3 that I had to apply plugins java and groovy before the grails plugin..

      No task with same name conflicts so far

    28. Hmmm…something else I need to take a look at. Too much to do! What error do you get if you don’t apply the java and Groovy plugins? It delegates to the Grails build, so those plugins shouldn’t be needed.

    29. Hi,

      When i am runnning command gradle compile its giving the following error msg. can you please guide me what will be the next step to use gradle in my grails APP.

      Thanks,
      sri

    30. forget to ad error message:

      Cause: Could not find method runtime() for arguments [org.slf4j:slf4j-log4j12:1.5.5, hsqld
      b:hsqldb:1.8.0.5, net.sf.ehcache:ehcache-core:1.7.1] on root project ‘keepUSAGreat’.

    31. If i use the same build.gradle code like above i am getting the error
      A problem occurred evaluating root project ‘MysampleGradle’
      Cause: No such property: id for class: org.gradle.api.internal.plugins.DefaultObjectConfigurationAction

    32. John Stoneham

      Notes for those finding this blog post: trying this with gradle 0.9-preview-3 and the latest snapshot, I have to change the second script above to say

      apply plugin: “grails”

    33. James Higgins-Thomas

      Many thanks for doing this! I’ve struggled trying to integrate a grails sub-component with non-grails projects before and this looks like it’s super simple. Haven’t gotten it working yet (I think my mind refuses to wrap around the maven/ivy dependency models). I am using Grails 1.3.4 and had to make two changes (so far):

      apply id: “grails” -> apply plugin: “grails” {as noted in the above thread}

      and

      compile “org.grails:grails-crud:1.2.0″, “org.grails:grails-gorm:1.2.0″ -> compile “org.grails:grails-crud:1.3.4″, “org.grails:grails-gorm:1.3.4″

      Now if I can just figure out the reference to org.jboss.netty#netty;3.1.5.GA …

    34. James Higgins-Thomas

      Ah, to that last point – add
      mavenRepo urls: ‘http://repository.jboss.org/nexus/content/groups/public-jboss/’
      to the second repositories {} collection…

    35. James Higgins-Thomas

      Or, better, refer to here: http://github.com/grails/grails-gradle-plugin for more current information

    36. Yes, I was going to refer you to that page :) Luke Daley has been doing some more work on the plugin, so might see a version 1.1 shortly. That reminds me, I need to revert the README back to version 1.0.

    37. Davide Cavestro

      Would it make sense some sort of automatic retrieving of plugins dependencies from the grails dependency-report? (if feasible)

    38. Sorry, I don’t understand the suggestion. Do you mean that the dependency reports should include plugin dependencies? If so, yes the reports should. Someone at SpringOne 2GX said that they would raise an issue for that if one didn’t already exist.

    39. Davide Cavestro

      Sorry Peter, I’ve been too vague.
      I’d mean it would be useful if the plugin could somewhat “guess” the dependencies instead of having to add them into the script.
      I actually ended up declaring the following dependencies for my grails project (after some attempts):

      dependencies {
      compile “org.grails:grails-crud:1.3.4″,
      “org.grails:grails-gorm:1.3.4″,
      “org.springframework.security:spring-security-web:3.0.3.RELEASE”,
      “org.hibernate:hibernate-tools:3.2.4.GA”

      runtime “org.slf4j:slf4j-log4j12:1.5.8″

      }

      Since they are all listed (among many others) in the ivy report generated by grails, I was trying to figure out if that data (maybe ivy internals?) could be used to provide an automatic “dependencies” declaration.

      Kind regards
      Davide

    40. Davide Cavestro

      Hi Peter, I have another question:
      how can I expose some info – in the “gradle way” – about the generated war? (see http://www.gradle.org/latest/docs/userguide/artifact_management.html)

      Let me explain:
      I’ve configured an Artifactory, an Hudson CI and linked them with the needed plugins (http://wiki.hudson-ci.org/display/HUDSON/Gradle+Plugin http://wiki.jfrog.org/confluence/display/RTF/Hudson+Artifactory+Plug-in http://wiki.hudson-ci.org/display/HUDSON/Artifactory+Plugin) but using a free-style job based on a gradle script that uses the grails-gradle-plugin I miss a declaration to let the gradle-artifactory plugin upload them to artifactory… something like
      artifacts {archives …}

      In other words hudson doesn’t upload to artifactory the gradle-generated war cause (I suppose) gradle doesn’t know about it (since it is built through grails’ build system).

      Kind regards
      Davide

    41. It wouldn’t be possible to guess the dependencies because the build wouldn’t know what should be included in the project and what not. Not all Grails applications would need GORM for example. What if you wanted to use logback rather than log4j? What the plugin could do is provide a default set of dependencies for a straightforward Grails application with HSQLDB and log4j. That would probably help.

      I need to get back to you on the WAR question.

    42. On the war front, I’m not sure what needs to be done because I don’t know how the ‘artifacts {}’ declaration works. I suggest you ask on the Gradle mailing list. Perhaps you just need to specify the task ‘assemble’ or ‘grails-war’ as the source of the archive? Someone on the Gradle list should be able to give us a starting point.

    43. Davide Cavestro

      Hi Peter, thanks for your quick replies.
      I’ve found some threads dealing with the task of exposing the produced artifacts:
      - http://gradle.1045684.n5.nabble.com/Creating-and-populating-new-configurations-td1435748.html#a3240755
      - http://gradle.1045684.n5.nabble.com/Migrating-multi-module-ant-build-to-gradle-howto-declare-built-artifacts-td1432137.html

      and till now I’ve understood that I can add artifacts using the API (instead of the DSL), and the artifactory plugin identifies the gradle output artifacts using the configuration of its ‘buildInfo’ task, as you can see from the following snippets I extracted from the plugin sources (org.jfrog.build.extractor.gradle.GradleBuildInfoExtractor)

      BuildInfoRecorderTask birTask = (BuildInfoRecorderTask) subProject.getTasks().getByName(“buildInfo”);

      //the the calculateArtifacts is called passing birTask.getConfiguration()

      private List calculateArtifacts(Configuration configuration, Project project) throws Exception {
      List artifacts = newArrayList(
      transform(configuration.getAllArtifacts(), new Function() {
      public Artifact apply(PublishArtifact from) {

      Hence I’ve written a task such this

      task publishWar(
      //commented only to reduce the overall build time
      /*dependsOn: “grails-war”*/
      ) {
      configurations.add “buildInfo”
      configurations.buildInfo.addArtifact(new DefaultPublishArtifact(“myWar”, “war”, “war”, null, new Date(), file(‘target/myWar.war’)))
      configurations.each {conf->
      println “conf: ${conf}”
      conf.artifacts.each {artifact->
      println ” artifact: ${artifact}”
      }
      }
      }

      that produces the following log:

      10:30:13 conf: configuration ‘:buildInfo’
      10:30:13 artifact: DefaultPublishArtifact CustomerDemand:war:war:null
      10:30:13 conf: configuration ‘:compile’
      10:30:13 conf: configuration ‘:grails_bootstrap’
      10:30:13 conf: configuration ‘:runtime’
      10:30:13 conf: configuration ‘:test’
      10:30:13 :publishWar UP-TO-DATE
      10:30:14 :buildInfo

      but the file still isn’t uploaded… maybe the “buildInfo” configuration I’ve added on the fly is overwritten by the “buildInfo” task.
      Yesterday I asked on the gradle mailing list http://gradle.1045684.n5.nabble.com/Creating-and-populating-new-configurations-td1435748.html#a3240755
      and I’m waiting for a response.
      I’ve also just added a comment on the artifactory wiki http://wiki.jfrog.org/confluence/display/RTF/Gradle+Artifactory+Plugin?focusedCommentId=14811595#comment-14811595
      If necessary I will start a new thread on gradle mailing list.

      Thank you
      Davide

    44. Davide Cavestro

      Hi Peter,
      I’m waiting for Gradle Artifactory Plugin support for http://issues.jfrog.org/jira/browse/GAP-35.

      In the meantime I have to ask you another thing (maybe partially related to my previous comment about dependencies http://www.cacoethes.co.uk/blog/groovyandgrails/building-a-grails-project-with-gradle#comment-1173):
      Provided that I have a gradle script declaring only the following dependencies

      dependencies {
      compile “org.grails:grails-crud:1.3.4″,
      “org.grails:grails-gorm:1.3.4″,
      “org.springframework.security:spring-security-web:3.0.3.RELEASE”,
      “org.hibernate:hibernate-tools:3.2.4.GA”

      runtime “org.slf4j:slf4j-log4j12:1.5.8″

      }

      I noticed that the war generated using the grails-gradle-plugin brings wrong versions for the included grails plugins.
      For instance, my application.properties ha an entry like

      plugins.jquery=1.4.2.5

      and during the gradle script execution (from an Hudson job) I get

      11:37:37 :grails-war
      11:37:37 Running pre-compiled script
      11:37:37 Environment set to production
      11:37:38 Setting non-interactive mode
      11:37:39 Plugin [gwt-0.5.1] not installed. …
      11:37:39 Plugin [app-info-0.3] not installed. …
      11:37:39 Plugin [smartgwt-0.1.1] not installed. …
      11:37:39 Plugin [dynamic-controller-0.2.1] not installed. …
      11:37:39 Plugin [hibernate-1.3.4] not installed. …
      11:37:39 Plugin [google-visualization-0.2.3] not installed. …
      11:37:39 Plugin [jquery-1.4.2.5] not installed. …
      11:37:39 Plugin [tomcat-1.3.4] not installed. …
      11:37:39 Plugin [spring-security-core-1.0.1] not installed. …
      11:37:39 Plugin [compress-0.4] not installed. …
      11:37:39 Resolving new plugins. Please wait… …

      from which you can see it claims the version 1.4.2.5 of jquery plugin (among others) is not installed. The problem is that it subsequently downloads version 1.4.3.2 as you can see here

      11:37:46 Plugin dependency [jquery] not found. Attempting to resolve… …
      11:37:46 Resolving plugin jquery. Please wait…
      11:37:46
      11:37:50 Downloading: http://svn.codehaus.org/grails-plugins/grails-jquery/tags/RELEASE_1_4_3_2/grails-jquery-1.4.3.2.zip
      11:37:52 Download complete.
      11:37:53 Installing zip /home/tomcat/.ivy2/cache/org.grails.plugins/jquery/zips/jquery-1.4.3.2.zip… …
      11:37:53 [mkdir] Created dir: /mnt/workspace/jobs/myjob/workspace/build/plugins/jquery-1.4.3.2
      11:37:53
      11:37:53 [unzip] Expanding: /home/tomcat/.ivy2/cache/org.grails.plugins/jquery/zips/jquery-1.4.3.2.zip into /mnt/workspace/jobs/myjob/workspace/build/plugins/jquery-1.4.3.2
      11:37:53
      11:37:53 Installed plugin jquery-1.4.3.2 to location /mnt/workspace/jobs/myjob/workspace/build/plugins/jquery-1.4.3.2. …
      11:37:53 Executing jquery-1.4.3.2 plugin post-install script …
      11:37:53 Plugin jquery-1.4.3.2 installed

      The question is: Why it uses another version for the jquery plugin?

    45. I’m trying to build an existing Grails 1.3.5 project with this gradle plugin.
      I already had to add dependencies for slf4j and ehcache to make get
      past a couple of exceptions but now I’m having trouble with this one
      when I run “gradle grails-run-app”:

      Caused by: java.sql.SQLException: No suitable driver found for
      jdbc:hsqldb:mem:grailsDB
      at java.sql.DriverManager.getConnection(DriverManager.java:602)
      at java.sql.DriverManager.getConnection(DriverManager.java:154)
      at $Proxy34.getMetaData(Unknown Source)

      What I don’t understand is why it’s looking for hsqldb since my data
      source is all mysql (from DataSource.groovy):

      dataSource {
      pooled = false
      driverClassName = “com.mysql.jdbc.Driver”
      }

      Here is my build.gradle file:

      buildscript {
      repositories {
      mavenCentral()
      mavenRepo urls: “http://repository.jboss.org/maven2/”
      }

      dependencies {
      classpath “org.grails:grails-gradle-plugin:1.0″,
      “org.grails:grails-bootstrap:1.3.5″
      }
      }

      apply plugin: “grails”

      repositories {
      mavenCentral()
      mavenRepo urls: “http://repository.jboss.org/maven2/”
      }

      dependencies {
      compile “org.grails:grails-crud:1.3.5″,
      “org.grails:grails-gorm:1.3.5″

      runtime “org.slf4j:slf4j-log4j12:1.5.5″,
      “net.sf.ehcache:ehcache-core:1.7.1″,
      “mysql:mysql-connector-java:5.1.5″
      }

      Did I miss something?

    46. [...] to use Gradle because it looks really easy to read, so I gave it a go. My start point was this article by Peter Ledbrook but it was confusing because the build script contains errors. So after reading the comments, I [...]

    Leave a reply