Comments on: Building a Grails project with Gradle

By: Gradle on Grails « alexcuesta

Gradle on Grails « alexcuesta — Tue, 21 Dec 2010 14:27:25 +0000

[...] 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 [...]

By: Sebastien Arbogast

Sebastien Arbogast — Sat, 04 Dec 2010 16:51:30 +0000

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?

By: Davide Cavestro

Davide Cavestro — Mon, 08 Nov 2010 13:56:27 +0000

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?

By: Davide Cavestro

Davide Cavestro — Fri, 29 Oct 2010 09:18:55 +0000

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

By: Peter

Peter — Fri, 29 Oct 2010 07:13:44 +0000

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.

By: Peter

Peter — Fri, 29 Oct 2010 07:09:43 +0000

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.

By: Davide Cavestro

Davide Cavestro — Thu, 28 Oct 2010 13:56:06 +0000

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

By: Davide Cavestro

Davide Cavestro — Thu, 28 Oct 2010 12:28:53 +0000

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):

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

By: Peter

Peter — Sun, 24 Oct 2010 13:36:53 +0000

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.

By: Davide Cavestro

Davide Cavestro — Thu, 21 Oct 2010 14:10:24 +0000

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