Dealing with JRuby and jars

Charles Oliver Nutter headius at
Thu Jan 12 13:11:49 EST 2012

On Mon, Jan 9, 2012 at 2:07 PM, Luis Lavena <luislavena at> wrote:
>> JRuby users are using JVM libraries. That's obviously a big selling
>> point of JRuby. They're also living in the Ruby world, and use
>> RubyGems, Bundler, etc. They don't want to have to manage dependencies
>> multiple ways.
>> Ruby world revolves around RubyGems and Bundler. Java world revolves
>> around Maven. We want to integrate the two for JRuby users in a way
>> that RubyGems,, and Bundler folks can accept.
>> JRuby currently supports installing jars from Maven at the "gem"
>> command line, but that's the only place it works. does
>> not allow us to push gems with maven dependencies, and Bundler does
>> not recognize maven dependencies.
> What about a extension to Gem::Installer provided by JRuby that uses
> Gem::Specification metadata field?
> (of Course, RubyGems master at this time)

We want the external libraries to be fully functional gems. JRuby
already supports installing them like this (I know colons are bad,
we'll figure out something else):

gem install mvn:org.clojure:clojure

This creates a gem on the fly and installs it, and any scripts, tools,
etc that use RubyGems see it as just another gem.

>> What we need:
>> * A way for RubyGems to understand Maven artifacts and dependency
>> graphs and fetch them. We have that at the command line, but it's via
>> our own patches.
> Gem::Installer provides pre and post install hooks.
> You can't use rubygems/defaults/#{RUBY_ENGINE}.rb ?

I do not want to use a hook to fire a separate install process; we
want those jars to be gems and have their dependencies resolved like
gems. Maven artifacts come with a list of dependencies that we map
into RubyGems dependencies. For example:

system ~/projects/jruby $ gem install mvn:junit:junit
Successfully installed mvn:org.hamcrest:hamcrest-core-1.3.r.2-java
Successfully installed mvn:junit:junit-4.10.0-java
2 gems installed

The junit gemspec looks like this:

>> * A way for to allow gems that have Maven dependencies.
>> The alternatives to this are pushing gems that *just* wrap a jar file
>> (some of them very large) or hosting a JRuby-specific I
>> don't like either of those options.
> I vote for metadata usage.

I don't understand why we can't just push gems that have maven
dependencies. Because they depend on Java libs, they only work on
JRuby anyway. Because they're used on JRuby, the maven dependencies
will resolve at install time.

>> * A way for Bundler to recognize Maven dependencies as though they are gems.
> Dunno how Bundler installer gems, so can't comment. I was guess it
> uses Gem::Installer and didn't reinvent the wheel.
> (Isolate at least uses it)

Yeah, I need to investigate how it works. I know it does its own
dependency resolution cycle.

>> I'm looking for thoughts and suggestions on how we can make this
>> easier. It's one of the biggest headaches for JRuby users right now,
>> since they have to use multiple mechanisms to track dependencies. I
>> also don't want to flood with a bunch of giant jar-only
>> gems when we can simply source them from Maven mirrors.
>> So...what do you think?
> On a different project I've started to work on a plugin that uses this
> metadata information to install missing binaries, similar to what you
> want to accomplish for JRuby.
> Since metadata is not available yet, what if you use spec.requirements array?
> Something like:
> do |s|
>  s.requirements = [
>    "",
>    "maven:junit.junit-4.10"
>  ]
> end
> $ gem spec --local pkg/testext-0.0.1.gem
> requirements:
> -
> - maven:junit.junit-4.10
> rubyforge_project:
> That would work?

I don't see that it works better than us just installing them as gems.
The issue I have is that by having it as a separate post-install hook,
every tool that uses RubyGems or Bundler to pull in dependencies has
to be modified to also know how to fetch those libraries and include
them. If they're just gems, the normal logic just works...

- Charlie

More information about the RubyGems-Developers mailing list