Posts Tagged ‘Gradle’
Gradle, Lift, and Google App Engine January 21, 2012 | 08:34 pm

I’m getting back into the game a little bit, and I decided to take a look at Lift for web development. After an initially promising experience, I became totally unhappy with Eclipse (it began forgetting I had Google App Engine libraries on the classpath after every clean). So I moved back to the command line. The recommendation to use Simple Build Tool or Maven for Lift put me off: SBT is pretty weak for a build tool, and Maven is…well…Maven, off to download the Internet. So I went back to Gradle.

For the record, I’m using Objectify for my Google App Engine development, because JPA gets you into that whole ugly ORM conceptual space without need: there’s no “R” in GAE, so you might as well deal with it in a more natural way.

So, given that situation, I came up with this build.gradle script. (Forgive the ugly organization, but this is actually the relevant points extracted from a multi-project build.)

buildscript {
   repositories {
      add(new org.apache.ivy.plugins.resolver.URLResolver()) {
          name = 'GitHub'
          addArtifactPattern '[organisation]/[module]/[module]-[revision].[ext]'
  dependencies {
    classpath "bmuschko:gradle-gae-plugin:$gaePluginVersion"
apply plugin:'java'
// Buildscript dependencies and repositories
repositories {
  mavenRepo name:'scala-releases', url:''
  mavenRepo name:'objectify-appengine-releases', url:''
  mavenRepo name:'sonatype-releases', url:''
  mavenRepo name:'sonatype-snapshots', url:''
  add(new org.apache.ivy.plugins.resolver.URLResolver()) {
      name = 'GitHub'
      addArtifactPattern '[organisation]/[module]/[module]-[revision].[ext]'
// Universal dependencies
dependencies {
  compile "org.encog:encog-core:$encogVersion",
  testCompile "junit:junit:4.5"
// Now the Scala stuff
apply plugin: 'scala'
dependencies {
  scalaTools "org.scala-lang:scala-compiler:$scalaVersion",
   compile "org.scala-lang:scala-library:$scalaVersion"
  testCompile "org.scala-tools.testing:specs:1.6.1",
apply plugin:'war'
dependencies {
  compile "net.liftweb:lift-webkit_$scalaVersion:$liftVersion",
  testCompile 'org.mortbay.jetty:jetty-util:6.1.22',
  providedCompile 'javax.servlet:servlet-api:2.5'
apply plugin: 'gae'
dependencies {
    compile "com.googlecode.objectify:objectify:$objectifyVersion"
    gaeSdk "$gaeVersion"
gae {
  downloadSdk = true
  disableUpdateCheck = true // Error with HTTPS
  appcfg {
    email = ''
    logs {
      append = true
      severity = 1
      ouputFile = file('build/logs.txt')

I stash versions in the file, which looks like this (it’s a lot more details than you actually need):

scalaVersion = 2.9.1
liftVersion = 2.4-RC1
gaePluginVersion = 0.5.2
objectifyVersion = 4.0a2
guavaVersion = 11.0.1
commonsLang3Version = 3.1
commonsLangVersion = 2.6
commonsIoVersion = 2.1
commonsCollectionsVersion = 3.2.1
encogVersion = 3.1.0-SNAPSHOT
androidPluginVersion = 1.1.0
slf4jVersion = 1.6.4
gaeVersion = 1.6.1

If you start Lift up at this point (using gradle gaeRun), there are errors about Lift not having permission to mess with the thread pool.

Now, here’s the amazing magic trick which I found documented nowhere but discovered while digging through the Lift source code. It’s an astounding and miraculous trick which is necessary in order to get Lift to work on Google App Engine.

In the file ./src/main/resources/props/default.props, make sure to have this set:


That’s it. You do that, Google App Engine works. You don’t do that, it won’t. Magic!

Newly Minted: JavaCC/JJTree Plugin for Gradle May 11, 2011 | 07:57 pm

I used to have a hackish JavaCC plugin under my Gradle-Plugins project, but I have ported it over to the Compiler plugins infrastructure that I announced before, and also added JJTree as part of the mix. This new approach solves a myriad of annoying edge cases in the old JavaCC plugin. The biggest benefit of the new version is that the process now integrates seamlessly into the normal Java compile, so you don’t have to split up your Java code into multiple different places. The second biggest benefit is that you can have more than one JavaCC per project (you now get one per source set, like in all the other languages).

Relevant pages with hopefully obvious URLs:

This is probably it for compilers for the moment. Left to my own devices, I’ll be releasing compilers for Ashlar (my own language) and BiteScript next, but they’re going to be a while into the future. An update to the Mirah one will be forthcoming when Mirah hits a slightly more stable point.

DZone Videos of Me and What I’ve Been Up To June 23, 2010 | 02:34 pm

In case you fear I’ve fallen off the face of the planet completely, here’s some evidence to the contrary. DZone put up two video interviews of me: one on Gradle and open source and one on Grails plugins and domain objects.

Aside from my summer field education placement at a church in Yanceyville, NC, I’ve been working on and The Indie3 Project. I’ve also been doing some open source work on figuring out the EPA’s MOVES model (GPL FTW!) and my programming language, Ashlar. Also researching perpetration induced traumatic stress (PITS), as well as dogs. With all that, my blogging has dropped to pretty much zero.