Archive for the ‘Gradle’ Category
Open Source Drop: GitHub as a Maven Repo for Gradle, a JSON parser library and client, and JavaCC Plugin for Gradle April 23, 2012 | 03:19 pm

This is an announcement of a bunch of open source code that I’ve just released.

Using GitHub as a Maven Repository for Gradle

If you’re using Gradle for your JVM builds (and you should be) and GitHub for your open source project infrastructure (and you should be), then you might be pleasantly surprised to know that you can use GitHub as a Maven repository, which means that your library can be deployed to and served from GitHub’s own cloud infrastructure.

Your clients add this line to their Gradle build scripts:

apply from:""

And at that point, they can draw from anything deployed on GitHub. Good times!

For more information (including the five lines of code necessary for you to deploy to GitHub), see the README for the RobertFischer/gradle-github-dev project.

JSON Parser Library

A long while back, I was pissed off at the available JSON parsing libraries, so I wrote my own JavaCC-drived JSON parser library. It supports a fair bit of the broken JSON that is out in the wild, and is screaming fast. For more information, see the README for the RobertFischer/json-parser project.

JSON Client for the JVM: Resty

I’ve been playing around with a bunch of different JSON clients for interacting with a REST service (GitHub’s API v3) on the JVM, and I didn’t really like any of them. All of them felt WAAAAAAAAAAAY too Java-y, and I was looking for something much simpler. RESTClient for Groovy was nice, but I had trouble debugging the errors going to and from the server. After much searching, the best I found was beders’s Resty library, but it had a problem in that it couldn’t parse JSON arrays at the top level. So I forked it.

You can check out my version of Resty, which uses my more fault-tolerant and faster JavaCC JSON parser (see above) and can parse top-level arrays. There’s also substantially improved error handling, and it’s now built using Gradle instead of Maven because XML’s pointy brackets make my eyes bleed.

JavaCC/JJTree Compiler Plugin for Gradle

Finally, I’ve updated my JavaCC/JJTree compiler plugin for Gradle. This also involved updating the compiler-base plugin. Both were overdue for an update to support Gradle 1.0, and updating them was really a joy, since it meant ripping out a lot of bad code and replacing it with newfangled Gradle API calls.

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 = '[email protected]'
    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.

New Gradle Plugin: DepNames November 20, 2010 | 10:34 am

I just released the DepNames plugin for Gradle. It’s part of my gradle-plugins collection, appearing in version 0.6.6. You can read the description with an example from the README, but the basic idea is that you can create “keywords” for your common external dependencies.

So this line:

dependencies {
  compile "org.apache.felix:org.apache.felix.framework:3.0.1"

Becomes this line:

dependencies {
  compile felix

And if you can upgrade your definition of felix in one place and all your projects get the same upgrade. The dependency keywords can be defined in either the root project or globally (with the root project definitions trumping the global ones).

JavaCC Plugin for Gradle September 21, 2010 | 02:19 pm

Quick announcement: I added a JavaCC plugin (which also supports JJTree) to Gradle Plugins. This is the 0.6.2 release.

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.

Gradle-Plugins 0.5.1 released January 5, 2010 | 10:35 am

Thanks to Jeppe Nejsum Madsen, the Gradle-Plugins just released version 0.5.1. It’s a minor bugfix release: if you didn’t have a GEMS_HOME kicking around anywhere on your system, we threw a NPE. The solution was to make project.tryRelativePath handle null input more nicely.