Enfranchised Mind » Groovy

log.debug { "$toStringMe only if necessary!" }

Robert Fischer — Fri, 19 Mar 2010 18:02:10 +0000

I’ve just updated the @WithLog AST transform for Groovy. In case you don’t know, that’s my project over at GitHub which allows you to turn:

import org.apache.log4j.Logger
 
class Foo { 
  static log = Logger.getLogger(Foo)
  /* ... */
}

into

@WithLog
class Foo {
  /* ... */
}

Three big changes in the new release. First, I switched to using Gradle for the build system, because Gradle is awesome. Second, I OSGi-ified the archive and released it to the Maven repo at http://repo.smokejumperit.com, so I’m now Java infrastructure compliant (thank you, Gradle, for making that a no-brainer). Third, I provided the ability to use an enhanced Logger implementation (unoriginally called WithLogLogger) — see the README for full details, but basically it means you can save the toString() evaluation on your logging messages if you wrap the logging GString in a Closure. If you use this, though, you’ll have to schlep around the Groovy-WithLog-0.2.jar file with your runtime code. If you’re using Maven/Ivy/Gradle/whatever, see the end of the README for repo information.

The @WithLog code is still released under the WTFPL.

This post was by Robert Fischer, written on March 19, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/log-debug-tostringme-only-if-necessary/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/log-debug-tostringme-only-if-necessary/

This article was a post on the EnfranchisedMind blog. EnfranchisedMind Blog by Robert Fischer, Brian Hurt, and Other Authors is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Oh, Gradle, You Made My Heart Skip a Beat

Robert Fischer — Fri, 27 Nov 2009 15:28:59 +0000

As I just mentioned, I’ve been working on some Gradle plugins. I’ve been using Gradle in my polyglot programming book, and there’s a stunt (namely, running Cucumber in a Java/Groovy/Scala build) that I’d like the user to be able to do without too much hassle. The easiest way is to say, “Hey, use this plugin and let the magic fly”.

In doing development, I’m spending some time pushing through integration tests, and in so doing, I wanted to deploy various versions to a Maven repository and pull them back down.

Creating a Maven repository for SmokejumperIT was pretty simple.

Create a space on the internet for the repository which is accessible via public-key-authenticated SCP. In my case, it’s http://repo.smokejumperit.com.

Create a configuration in the Gradle build file for the JARs needed to deploy:

configurations {
    deployerJars
}
 
repositories {
  mavenRepo urls: "file://${System.properties['user.home']}/.m2/repository/"
  mavenCentral()
}
dependencies {
  deployerJars 'org.apache.maven.wagon:wagon-ssh:1.0-beta-2'
}

Note: The part in the repositories block is in every build file that I have, so I’m working on a plugin (working title PreconfigPlugin) that will automatically add that in.

Configure the uploadArchives task. I had it delegate to various System properties that I set when I run the build script.

uploadArchives {
  repositories.mavenDeployer {
    def repoUser = System.properties['sjit.repo.user']
    configuration = configurations.deployerJars
    repository(url: "scp://repo.smokejumperit.com/home/$repoUser/repo.smokejumperit.com/") {
      authentication(
        userName: repoUser,
        privateKey: new File(System.properties['sjit.repo.keyFile']).absolutePath,
        passphrase: System.properties['sjit.repo.passphrase']
      )
      pom {
        groupId='com.smokejumperit'
        artifactId='gradle-plugins'
        version='0.2-SNAPSHOT'
      }
    }
  }
}

Run gradle upload.

That’s all it took. Even better, it does all the funky snapshot management on its own: see http://repo.smokejumperit.com/com/smokejumperit/gradle-plugins/0.2-SNAPSHOT/ for the beautiful timestamped results!

This is how builds should be: stupid-simple to do the right thing.

Comments

November 27, 2009, Hamlet D'Arcy wrote: I'd like to hear what you think about Gradle being the result of applying Evans-style Domain Driven Design to build systems. Is a strong domain model for enterprise projects really a great benefit?
March 23, 2010, Blog bookmarks 03/24/2010 « My Diigo bookmarks wrote: [...] Oh, Gradle, You Made My Heart Skip a Beat [...]

This post was by Robert Fischer, written on November 27, 2009.
Comment on this post: http://enfranchisedmind.com/blog/posts/gradle-maven-repo-snapshots/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/gradle-maven-repo-snapshots/

Announcing Gradle-Plugins

Robert Fischer — Thu, 26 Nov 2009 00:16:20 +0000

A lot of people know that I have contributed a lot of Grails plugin work, even if my take on contributing is somewhat controversial. Well, I’m continuing on with that approach of plugin contributions, but now for Gradle, the world’s most awesome build system. You can check out the plugins at http://github.com/RobertFischer/gradle-plugins/. Be sure to scroll down to see the README file with all of its goodness.

Currently, there are just two plugins: one to get at classloaders and one to execute shell commands. I’ll probably have some JRuby/Cucumber, maybe JAVACC, and almost certainly some conventional development plugins sometime in the future.

Note that I’m releasing the Gradle plugins under the CC0 (which is a classier form of my beloved WTFPL). Here are the details:

To the extent possible under law, Robert Fischer has waived all copyright and related or neighboring rights to Smokejumper IT Gradle Plugins. This work is published from United States.

Comments

November 25, 2009, Hamlet D'Arcy wrote: great news. Why not just submit the plugins back to the Gradle project?
November 25, 2009, Robert Fischer wrote: @Hamlet Is there a way to do that? I wasn't exactly sure how plugins in the Gradle source code worked, but I'd be more than happy for the code to make it into Gradle core.

This post was by Robert Fischer, written on November 25, 2009.
Comment on this post: http://enfranchisedmind.com/blog/posts/announcing-gradle-plugins/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/announcing-gradle-plugins/

“Holy Crap, That Worked!”: Running JRuby/Cucumber from Gradle

Robert Fischer — Sun, 01 Nov 2009 00:23:52 +0000

I’m working on some code for my book and I’m trying out Swinger, which is a Cucumber library for Swing. I wanted to integrate it into my build (which is Gradle), but was running into issues. The problem is that I was pulling JRuby-Embed from the central Maven repo, which meant that I could only use the JRuby classes by way of Gradle’s fancy classloader stunts. The issue is that JRuby does some of its own classloader stunts, so there were classloader issues. The issue resulted in error messages that looked like this:

Caused by: org.jruby.exceptions.RaiseException: library `enumerator' could not be loaded:
java.lang.ClassNotFoundException: org.jruby.libraries.EnumeratorLibrary
	at (unknown).new(:1)
	at (unknown).(unknown)(:1)

After tracking through the JRuby source code, I found that RubyInstanceConfig was grabbing the thread context classloader instead of the classloader used to load itself. I don’t know what that classloader was set to, but resetting it solved the issue.

Here’s the resulting Gradle script, which at least runs the gem installs and a Cucumber run:

import org.jruby.Main as JRuby
 
buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    classpath "org.jruby.embed:jruby-embed:0.1.2"
  }
}
 
task checkGradle << {
  println "OK"
}
 
task gems << {
  def gemsDir = "./build/gems"
  if(!new File(gemsDir).exists()) {
    runJRuby("gem install -i $gemsDir --no-rdoc --no-ri cucumber")
  }
}
 
task runTest(dependsOn:gems) << {
  def cukeHome = new File('./build/gems/gems').listFiles().find {
    it.name.startsWith('cucumber-')
  }
  runJRuby("$cukeHome/bin/cucumber src/test/features")
}
 
def runJRuby(cmdArg) {
  Thread.currentThread().setContextClassLoader(JRuby.class.classLoader)
  println "Running JRuby: $cmdArg"
  JRuby.main("-S $cmdArg".split())
}

This post was by Robert Fischer, written on October 31, 2009.
Comment on this post: http://enfranchisedmind.com/blog/posts/jruby-cucumber-gradle/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/jruby-cucumber-gradle/

null Sucks: A Case in Point

Robert Fischer — Sat, 17 Oct 2009 19:30:57 +0000

Take a look at this API: ClassNode#addProperty. Turns out that if you pass null into getterBlock and setterBlock, you get the default implementations. Maybe¹. Normally passing null around blows up in unhelpful ways, but here null is a useful value. How is a programmer to know?

I’m increasingly convinced that immutability² and strong type systems in languages aren’t just about concurrency or letting the computer optimize or catching bad code early. Increasingly, I’m convinced that the key value they provide is clear, meaningful, and maintainable code. Which is really the key problem in software development these days, isn’t it?

¹ As of this writing, it’s an outstanding question if the compile phase of the AST transformation impacts whether or not the null values are translated: mailing list conversation.
² See this nice presentation from Rich Hickey, author of Clojure.

Comments

November 6, 2009, New PeriodicalUpdater Feature, and, Mutable Data Sucks: A Case in Point | Enfranchised Mind wrote: [...] said before that null sucks, but now I’ve got a case in point for why mutable data sucks, [...]

This post was by Robert Fischer, written on October 17, 2009.
Comment on this post: http://enfranchisedmind.com/blog/posts/null-sucks-a-case-in-point/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/null-sucks-a-case-in-point/