Maven dependency management

I am interesting in using maven repos to manage jar dependencies for my
jruby projects. I’ve taken a look at a few projects like jbundler and
maven_gem but I have not had much success. I also took a look at some
gems
like nokogiri and it looks like the sparklemotion team just includes the
xerces jar in their source repo.

As a result of my “research” it’s not clear to me how to idiomatically
manage jar dependencies for jruby projects. Does anyone have advice?

Ariel V.
e-mail: [email protected]
website: http://blog.arielvalentin.com
skype: ariel.s.valentin
twitter: arielvalentin
linkedin: Sign Up | LinkedIn

it is a bit my personal topic, but first I would like to know where
jbundler failed ?

your observation with nokogiri is quite true and will hold probably for
all
gems which uses jar dependencies - they just include them into the gem
and
there is no way to find out on what jars are included and what version
of
the library that is. and of course there is no “good” to prevent having
multiple versions of the same library in classloader. if you have a gem
with such jars in your project there is no easy way to use that jar for
compiling your code against it ( beside dig into the installed gem and
locate the jar and add it to your compile classpath ), i.e. use that
xerces
from nokogiri for your own java code.

you can use bundler to manage you gems with their dependencies and you
can
use jbundler to manage jars and their dependencies. or you can use maven
to
manage both gems and jars. BUT there is no way to deal with those
vendored
jars which come in gems like nokogiri or even with jruby-1.7.x itself
(jline-2.11.jar, bcpkix-jdk15on-1.47.jar, bcprov-jdk15on-1.47.jar)

the situation is even more difficult when you have java project using
jruby
scripting-container, then any jar dependency from the java project is in
the parent classloader of jruby and any class loaded by a gem will look
at
the parent classloader first, i.e. nokogiri will not find its version of
xerces if the java project uses a different version of xerces. (I have a
patch for that ly
ing around since a couple of month - time to push it :wink:

from a practical point of view it looks like the current situation still
works for most projects and conflicts are rare and can be solved
somehow.
still I think gems for jruby should at least get a “formal” way to
declare
what jars they verndored. please see for a proposal
http://blog.mkristian.tk/2014/01/rubygems-with-java-extensions.html
which explains a way to handle such jar dependencies. jbundler and the
gem
artifacts from http://rubygems-proxy.torquebox.org/
do use that jar dependencies declared inside those requirements array
already. but I guess there are no such gems on rubygems.org which would
declare them. and having two tools will not make it “the way to build
gems
with jar dependencies”.

guess that is not really an answer to your question but maybe it helps
you
a little further.

  • christian

Kristian,

Thanks very much for your reply.

The specific problem that I faced with jbundler was that it did not
support
bundler’s switches such as binstubs and standalone. It just occurred to
me
that I could get around this problem by adding variables to
.bundle/config.

I glanced at your proposal and I really like what I see on the surface;
I
am definitely going to review it with a fine toothed comb and provide
you
with feedback!

Thanks,
Ariel V.
e-mail: [email protected]
website: http://blog.arielvalentin.com
skype: ariel.s.valentin
twitter: arielvalentin
linkedin: Sign Up | LinkedIn

*simplicity *communication
*feedback *courage *respect

On Sat, Jan 18, 2014 at 8:41 PM, Ariel V.
[email protected]wrote:

The specific problem that I faced with jbundler was that it did not
support bundler’s switches such as binstubs and standalone. It just
occurred to me that I could get around this problem by adding variables to
.bundle/config.

added an issue for that keep jbundler command line args in line with bundler · Issue #28 · mkristian/jbundler · GitHub

I glanced at your proposal and I really like what I see on the surface; I
am definitely going to review it with a fine toothed comb and provide you
with feedback!

that would be greatly appreciated !!

regards,
christian