Morris "Mojo" Jones

Mojo's blog banner

Tag: Groovy

  • “The Amazing Groovy Weight-Loss Plan” Scott Davis

    Notes from TheServerSide Java Symposium March 2009

    Scott Davis was the perfect presenter for the deadly “after lunch” session period. Interesting that his Groovy introduction is in a breakout room rather than the main ballroom, and there is not an empty seat in the house. Everyone is fascinated by these new powerful JVM languages, including me.

    Scott started by asking who was a Java programmer in the house, a silly question at a Java symposium. He followed by asking who were Groovy programmers, and two or three hands went up. Followed by “Aha! Just by adding one JAR file to your classpath, you’re all Groovy programmers too.”

    He immediately quit using slides, and went directly to live coding. Fabulous for a software talk! He started with a one-line “Hello, World” and then moved on to show off Groovy’s object and dynamic type features.

    He’s using javap to explore groovy-created class files and show how the underpinnings relate directly to the Java infrastructure.

    Admittedly, these powerful JVM languages are very seductive. They call them scripting languages, and yes, they’re great for scripting. But full powerful languages like Groovy, Scala, JRuby, Jython, and even JavaFX have enormous potential. I’m being torn in about five directions for new projects.

  • “Leveraging Groovy for building Java applications” Hans Dockter

    Notes from a talk at TheServerSide Java Symposium March 2009

    Hans is the project lead for a build system called Gradle. He presents it as a step beyond Ant and Maven.

    I think he has a point. His system uses Groovy scripts as build scripts instead of XML. The advantages of having a full language available in build scripts is pretty clear. (Try writing a conditional clause in Ant XML. Ewww!)

    Gradle is a build toolkit and collection of small frameworks, rather than one monolithic build framework. It seems to me like this is a step back toward customization and away from “convention over configuration.” But the truth is that one build convention can not serve all build situations, and there’s probably nothing more customized in individual companies than their build, test, production, and deployment environments.

    (At MyAds we built a custom version of the Maven Release plug-in just to support our version numbering system. One size does not fit all, especially in building applications.)

    Hans says it’s easier to write and use Ant tasks in Gradle than in Maven. Gradle is using dependency management based on Apache Ivy, which I’m not familiar with. He recognizes the value of dependency management as introduced by Maven, so I have a feeling Apache Ivy won’t disappoint. I crave good dependency management, even though it can lead to Maven dependency hell at times. Ivy appears to be leveraging the Maven dependency infrastructure, as well as supporting SVN dependencies.

    So I like the concept of using a full dynamic OO language for writing build scripts, especially if the API toolkit is sufficiently intuitive that it doesn’t have a large learning curve. Gradle is worth investigating.

    Link to presentation here.

    Gradle roadmap here.