Dealing with JRuby and jars

Charles Oliver Nutter headius at
Wed Jan 18 17:49:32 EST 2012

Answering below and then summarizing *exactly* how our maven gem stuff works.

On Tue, Jan 17, 2012 at 7:51 PM, Eric Hodel <drbrain at> wrote:
> On Jan 12, 2012, at 10:29 AM, Luis Lavena wrote:
>> So what you're suggesting, even you stated differently is that you
>> want to pollute with maven artifacts wrapped as gems?
> So I take this to mean that the clojure gem only exists on the user's machine while installed and not on nor anywhere else.

That is correct.

Maven artifacts are managed much like RubyGems, with a central server
(really many "centrals"). The main namespace is "group", which would
be something like org.jruby. Under group there's "artifact" which
would be "jruby" for the main JRuby library, "jruby-complete" for the
jruby jar that includes stdlib, and so on. All this is managed in an
XML-based specification file (pom.xml) which additionally contains
other library dependencies, library information (desc, authors, home
repo, web page), testing information, build information, and so on.
Maven is like RubyGems + Rake (+ 5000 other things) all in one.

JRuby's support for "maven gems" basically just uses Maven to fetch
the given library's pom.xml, convert that into a gemspec, and then
pass that off to RubyGems to install. We hook into spec retrieval and
file download in both cases, looking for "mvn" prefix to indicate that
we need to look at Maven Central instead of The
mechanism is fairly elegant, since RubyGems does all the version and
dependency walking.

At install time, the process goes like this:

* Our RubyGems recognizes that this is an mvn: gem and uses our Maven
logic to build a gemspec
* The gemspec is returned and RubyGems processes it as normal
* Dependencies that are also mvn: gems go through the same process
* Finally, when it comes time to fetch the actual gem, our RubyGems
again recognizes that it's a mvn: gem, fetches the jar file (or
whatever) for the Maven artifact, and wraps it up in a rough gem

The resulting gem only exists on the user's local system; it is
"virtual" in nature. The gem mostly just contains the jar file, but we
also throw in a few simple .rb files for easy loading, version
numbers, and getting the real path to the jar file on disk.

If the dependency restriction is dropped, that's 90% of our issues
solved. I fully endorse that change :)

The other piece that would be "nice to have" is making it possible for
gems to either:

a) automatically source pieces of them from another location; e.g.
pull the gem from but the jar from somewhere else


b) make it easier to hook the spec retrieval + gem fetch process

I prefer the latter, since it allows us to build the gems any way we
want, so long as we feed RubyGems a valid spec and provide it smarts
to get a .gem file in hand.

This thread is fine to discuss the additional support, I think.

Questions? Comments?

- Charlie

More information about the RubyGems-Developers mailing list