I have been helping out with adding features to the jruby-gradle-plugin. A couple of interesting (at least for me) design questions have come up.
Running JRuby Scripts : The current implemetation leverages ‘project.javaexec’ or ‘‘JavaExec’’ task, which measn that a seperate JVM is spun up. The question has come up whether it is better to embed jruby as execute that using the same JVM that gradle is running under. I can see both ways as having advantages.
Rakefiles: We are looking at the possibiliy of executing Rake as Gradle as tasks, or even possibly reflecting Rake targets as Gradle targets (if that is possible). Once again, would this be best to use the same JVM as Gradle?
Is there maybe somethign in the new Tooling API we should look at?
It’s generally best not to run it in the Gradle process. Running it in the Gradle process means the build user having less control over the JRuby environment and also opens up plenty of pollution possibilities. There’s a speed benefit in running embedded, but the increased stability of running as an external process trumps this.
As for how to do this. If you need richer IPC, we have an internal mechanism for communicating with forked JVMs. Take a look at the findbugs stuff if you want to go this route. Keep in mind this is internal though so can change at any time. That said, it hasn’t changed in a while.
With the rakefiles, I’m not sure about embedded vs. external process here. I think the same arguments for external process still hold.
Thanks for the feedback Luke. A point on the Rakefiles. I am thinking that it should model what gradle does with Ant tasks atm. For Ant, Gradle obviously relies on the native support Groovy has for Ant, but there is still enough to take as a parallel I would think.
For Ant tasks, does Gradle run them in the same JVM or separate? And what happens if you read in build.xml? Is it done inside or outside of the same JVM?