On 12/4/07, Alon Salant <[EMAIL PROTECTED]> wrote: > > Hey all, > > I've seen a few posts on this mailing list and in the JRuby JIRA looking for > gem management strategies that don't rely on a local installation of JRuby > and locally installed gems in a deployed Java + JRuby application. > > The application model I am looking at is a Java application built by Maven > that embeds JRuby scripts that have gem dependencies. I'd like to support a > deployment model that doesn't require a local install of JRuby and the > required gems. > > The primary issue appears to be that Ruby and RubyGems are heavily file > system dependent so are not friendly to having resources loaded from the > classpath. > > jruby-complete takes care of providing the JRuby and the core Ruby > dependencies with a strategy where core Ruby libraries are extracted at > runtime to the file system from the jar.
This is primarily because of the rubygems-needs-to-run-from-the-filesystem issue. It's either done the first time a gem install is attempted with the complete jar, or when requested. > I have been experimenting with a similar strategy for managing gem > dependencies and have a working implementation that I'd like to float out > here for comment. > > It goes something like this: > > Package [name]-[version].gem files in the Java application classpath. > Either at application startup or on demand (by modifying Kernel::gem) find > the desired gem if it is not already installed by scanning the root of the > classpath, ala Spring's PathMatchingResourcePatternResolver > (http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/core/io/support/PathMatchingResourcePatternResolver.html). > Extract and install the gem into an application-specific GEM_HOME using > Gem::Installer. > Done. This alone seems like it could be worthwhile, you simply will need to patch Kernel::gem to do the extraction and the gem install (see src/jruby/commands.rb and src/jruby/extract). > This enables packaging and deploying gems as jars (the .gem file in the root > of a jar) and managing these dependencies with Maven, including transitive > dependencies among gems. Well, not sure about Maven for managing gems, Rubygems seems to do that just fine. As long as your solution doesn't require Maven, it should be fine. (You of course are welcome to use whatever tools you want for yourself.) > > Goldspike (Rails on Tomcat) uses a similar strategy by bundling expanded > gems in WEB-INF and setting GEM_HOME to that location. > > I have a version of this working that first extracts the .gem file to file > system from the classpath by reading from a classpath resource InputStream. > I noticed that Gem::Format has a method for reading from an IO stream > (Gem::Format.from_io). It would be great to skip the intermediate extraction > step by using this method. I ran into trouble figuring out how to use the > InputStream from the classloader as an IO object in Ruby. I tried creating > an org.jruby.RubyIO object from the InputStream but get an error when > calling Gem::Format.from_io with the created object: > > /lib/ruby/site_ruby/1.8/rubygems/package.rb:411:in `new': Illegal seek > (Errno::ESPIPE) Looks like Rubygems wants to be able to seek through the package, but when creating RubyIO from an InputStream, it makes the resulting IO unseekable since we don't know whether the underlying stream supports it. Unfortunately we don't make it easy to register a seekable stream. A patch to RubyIO might be necessary in order to support this. Feel free to open a JIRA (http://jira.codehaus.org/browse/JRUBY) and attach patches there. Cheers, /Nick --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
