Building a Grails project with Gradle

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 thoughts on “Building a Grails project with Gradle

  1. Goran Ehrsson

    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. Rob Fletcher

    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. Peter Post author

    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.

  4. Peter Post author

    @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.

  5. Rob Fletcher

    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

  6. Goran Ehrsson

    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.

  7. Reiner Saddey

    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

  8. Peter Post author

    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

  9. Peter Post author

    @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.

  10. Reiner Saddey

    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

  11. Bryan Choate

    @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!

  12. Peter Post author

    @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.

  13. Ben Doerr

    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?

  14. Ben Doerr

    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.

  15. Peter Post author

    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.

  16. Todd

    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.

  17. 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?

  18. 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"
    }

  19. Peter Post author

    @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.

  20. Peter Post author

    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.

  21. Fred Grott

    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

  22. Peter Post author

    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.

  23. Srinivas

    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

  24. Srinivas

    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’.

  25. Srinivas

    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

  26. 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”

  27. 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 …

  28. 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…

  29. Peter Post author

    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.

  30. Davide Cavestro

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

  31. Peter Post author

    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.

  32. 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

  33. 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

  34. Peter Post author

    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.

  35. Peter Post author

    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.

  36. 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

  37. 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?

  38. Sebastien Arbogast

    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?

  39. Pingback: Gradle on Grails « alexcuesta

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>