JRuby/Gradle News

JRuby/Gradle 1.1 'Dresden' released

18 September 2015

Since our major 1.0 announcement at this past year’s JRubyConf EU we’ve had a pretty steady stream of improvements and bug fixes in a total of four patch releases (1.0.0 - 1.0.4), so we’re due for a big meaty feature release! The most impactful feature, sponsored in part by Lookout, Inc., is the support for dependency resolution without a 3rd party proxy.

By default, JRuby/Gradle relies on a third party instance of the rubygems-servlets proxy which represents a Rubygem repository in a Maven-compatible format, allowing tools like Gradle or Maven to prepare a dependency graph using Ruby gems. With 1.1, codenamed "Dresden", release we’ve embedded the proxy software directly into the Gradle process. With the rubygems() function, users can use gem dependencies from any repository, whether it’s a public repository like rubygems.org or an internal Ruby gem repository.

Currently this behavior is defaulted to off so users must explicitly enable it, e.g.:

build.gradle

/* add the latest jruby/gradle plugin */
buildscript {
    repositories { jcenter() }
    dependencies {
        /* allow Gradle to resolve anything between 1.1.2 and 1.2.0 (exclusive) */
        classpath "com.github.jruby-gradle:jruby-gradle-plugin:[1.1.2,1.2)"
    }
}
apply plugin: 'com.github.jruby-gradle.base'

/* Disable the default repositories so we can add our own */
jruby {
    defaultRepositories false
}

repositories {
    /* use jcenter() so we can get JRuby itself */
    jcenter()
    /* use our new rubygems() function to add a rubygems repo */
    rubygems('https://rubygems.org')
}

dependncies {
    gems 'rubygems:sinatra:1.4.5'
}

In our beta testing of this feature, users on JDK7 may need to increase their available "PermGen" space for more complex projects via the gradle.properties setting of: org.gradle.jvmargs="-XX:MaxPermSize=512m"

Once this functionality has been deemed stable, it will be enabled by default so please try it out, and as per usual, please report any bugs to the GitHub Issues page.

Other Notable Features

The full list of changes/fixes is rather long, so below is a summary of what we thing are nifty and notable features in 1.1:

#131: Provide a command-line property to change the version of JRuby at runtime (./gradlew -PjrubyVersion=9.0.1.0)
#211: Default to JRuby 9.0.1.0
#200: Reduced .jar file size by not packing cache/*.gem inside the archive.
#208: Ensure gradle.rb scripts use the same classpath, gems and jars as their j JRubyExec counterparts

Bug fixes

And of course some bug fixes, most of which were backported and released as part of JRuby/Gradle 1.0.4.

#195: Ensure released versions of the plugin are laid out in the Maven repository correctly (allows specifying a version range dependency on the plugin itself properly like in the above example)

v1.0.4 and a few squashed bugs

10 September 2015

We’ve just released a minor bug fix release of the 1.0.x branch of the JRuby/Gradle core plugins. We wanted to get a few bug fixes out to users before we release 1.1.0 - Dresden, a release which contains some great new features which are still baking in the oven.

Upgrading to this release is as easy as editing your build.gradle files:

build.gradle

buildscript {
    repositories { jcenter() }
    dependencies {
        classpath "com.github.jruby-gradle:jruby-gradle-plugin:1.0.4"
    }
}
apply plugin: 'com.github.jruby-gradle.base'

The full diff from 1.0.3 to 1.0.4 can be found here.

Improvements

#211: Upgrade to use JRuby 9.0.1.0 by default
#193: Avoid packing a redundant copy of jruby-mains inside packed jars

Bug fixes

#190: generated gradle.rb needs to follow the jars/gems setup we have everywhere else
#213: cannot resolve gems with ~> 0.10.4.0 to 0.10.4 the way bundler does
jruby-gradle-storm-plugin#21: enable easier subclassing of JRubyJar so subclasses can override properties cleanly.
#220: prepareJRubyJar doesn’t cache results and reinstalls gems every single run

Gradle Feature Spotlight: Continuous Build

01 September 2015

Earlier this year the Gradle project released version 2.5 with a heap of new features and improvements. One of the most touted of those features is an incubating feature (read: beta) named Continuous Build which automatically re-executes tasks after a file change. Rubyists may recognize that this functionality is similar to what the guard gem provides.

What makes "continuous build" special is that it makes use of the existing build data present in your Gradle build. Using a task’s inputs the continuous build feature can automatically "watch" the appropriate files to re-execute your task, or your tasks dependent tasks, automatically as they change!

For users JRuby/Gradle this means that upgrading to Gradle 2.5 or later, and ensuring your build.gradle declares task inputs and continuous build will "just work!" Consider the following example for running RSpec tests:

build.gradle

buildscript {
    repositories { jcenter() }
    dependencies {
        classpath "com.github.jruby-gradle:jruby-gradle-plugin:1.0.3" (1)
    }
}
apply plugin: 'com.github.jruby-gradle.base' (2)

dependencies {
    jrubyExec 'rubygems:rspec:3.3.0' (3)
}

import com.github.jrubygradle.JRubyExec

task spec(type: JRubyExec) {
    group 'JRuby'
    description 'Execute the RSpecs in JRuby'
    script 'rspec'
    inputs.source fileTree('spec').include('**/*.rb'), fileTree('lib').include('**/*.rb') (4)
}

1	Specify our dependency on the JRuby/Gradle base plugin
2	Apply the plugin to our current project
3	Define our RSpec gem dependency
4	Set our task inputs to the `.rb` files in `spec/` and in `lib/`

Using the build.gradle above, I can auto-execute my tests whenever a Ruby file inside of the spec/ (my tests) or lib/ (my code under test) with the following command:

% ./gradlew -t spec

Here’s some example output from my example project:

example-project git:(master) % ./gradlew -t spec
Continuous build is an incubating feature.
:spec

Randomized with seed 37453
..............................................

Finished in 0.52 seconds (files took 3.82 seconds to load)
46 examples, 0 failures

Randomized with seed 37453


BUILD SUCCESSFUL

Total time: 8.77 secs

Waiting for changes to input files of tasks... (ctrl-d to exit)

At this point the Gradle process is patiently waiting until I write my most recent changes, then it kicks off the same task:

Change detected, executing build...

:spec

Randomized with seed 64935
..............................................

Finished in 0.502 seconds (files took 3.5 seconds to load)
46 examples, 0 failures

Randomized with seed 64935


BUILD SUCCESSFUL

Total time: 7.341 secs

Waiting for changes to input files of tasks... (ctrl-d to exit)

Pretty neat huh?

What makes this functionality exceptionally powerful for JRuby/Gradle users is that it respects the task inputs but also the task dependency graph. If my spec task declares a dependency on the compileJava task, whenever my Java source code changes, that will trigger a re-execution of compileJava and in turn spec!

So when you’re authoring tasks, even if you’re not this feature right now, be sure to declare task inputs. That build metadata can unlock lots of interesting functionality as Gradle continues to improve!

Continuous build is one of many examples of powerful Gradle functionality which can easily used in JRuby/Gradle, I hope you find it useful!

JRuby/Gradle at JRubyConf EU 2015

16 August 2015

A couple weeks ago, Schalk, Christian and I were fortunate enough to participate in the wonderful JRubyConf EU 2015 in Potsdam Germany. In the days that preceeded the conference we pulled together and finished up what would become the 1.0 release of the core plugins. Just in time for my presentation to introduce the JRuby/Gradle toolchain to the audience.

Below is a video recoded by Confreaks.tv of the talk titled JRuby/Gradle: Bringing Java Powertools to Ruby:

The other sessions are also worth checking out as there was a lot of great, in-depth, technical content presented at the single-track one-day conference.

On behalf of the JRuby/Gradle core team, I’d like to thank the conference organizers (especially Tobi) for hosting such a wonderful event and allowing us the opportunity to participate. Hopefully we’ll be back next year with more to talk about!

JRuby/Gradle 1.0 Announced

04 August 2015

Less than one year after the JRuby/Gradle project was founded, we are pleased to announce the release of 1.0 for the core plugins, which includes the base plugin, the jar plugin and an alpha version of the war plugin. This release marks the stability of the core task and configuration APIs for the lifetime of the 1.x branch of development.

Notable Features

This release includes a number of notable features which can help developers build high quality Ruby projects, based on JRuby.

Defaulted to the major milestone release: JRuby 9.0.0.0
Native Java dependency resolution via Gradle’s built-in support of Maven repositories and with Gem dependency resolution via a rubygems.org proxy.
Execution of local Ruby script via the JRubyExec task
Execution of scripts provided by a gem dependency, e.g. rspec via JRubyExec task
Support for distinct configurations to isolate dependencies, even JRuby versions, between JRubyExec tasks.
Similar support for different configurations between JRubyJar tasks

Project History

The JRuby/Gradle project was originally started to address the challenges faced when attempting to build complex Ruby applications based on JRuby. With such applications it is desirable to leverage the vast libraries available to JVM-based languages, as well as many of the user-friendly gems built by Ruby developers

After trying to make multiple tools, which weren’t designed to support non-Java projects, work with Ruby R. Tyler Croy started building a prototype with Gradle to package up a JRuby application as a jar. Shortly after publishing the prototype, Schalke W. Cronje discovered the fledgling project and with his Gradle development experience helped bring it from a weekend hack project to a well-tested, well-structured set of Gradle plugins. Eventually Christian Meier, whose link:https://github.com/torquebox/rubygems-servlets] code helped make the project originally possible, joined the team to help improve support in JRuby itself for the different embedded operating modes that the JRuby/Gradle toolchain makes use of.