On Mon, Jan 9, 2012 at 2:07 PM, Luis Lavena <luislav...@gmail.com> 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, RubyGems.org, 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. RubyGems.org 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: https://gist.github.com/1602109 >> * A way for RubyGems.org 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 RubyGems.org. 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 RubyGems.org 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: > > Gem::Specification.new do |s| > s.requirements = [ > "maven:org.something.foo.whatever", > "maven:junit.junit-4.10" > ] > end > > $ gem spec --local pkg/testext-0.0.1.gem > > requirements: > - maven:org.something.foo.whatever > - 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 _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers