This sounds great to me. Once you get rid of Spring as a dependency I would expect it to be downright attractive. If we automatically included this as part of jruby-complete I would be mildly worried about performance of loading since it would require a classpath search. In the past we refactored load/require to make sure we were not doing that searching first since it was really slow and linear to the amount of classes/jars it needed to search through.
Making from_io work would be even better of course. -Tom On Dec 7, 2007 12:23 PM, Alon Salant <[EMAIL PROTECTED]> wrote: > > I've gotten this to a point that is working well for me. > > https://svn.carbonfive.com/public/carbonfive/jruby/jrubygems/trunk > > JRubyGems extends RubyGems to support loading gem dependencies from the Java > classpath. > > There is a java component built with Maven 2 and a Ruby component structured > as a gem. The gem was bootsrapped with newgem so there's a lot of template > files in there. lib/ and tests/ have the meat, particularly > test/test_jrubygems.rb. The artifact of the Java component is built and in > ruby/lib so you don't have to build it to check this out. > > Here's what I've done: > > 1. Gem.activate searches the Java classpath for the .gem file if it is not > already installed. > 2. If found, extract the .gem to the filesystem and install it with > Gem:Installer. > 3. If the gem has additional dependencies, steps 1 & 2 will be run for each > dependency before the gem is installed. > > That's about it. > > A few comments: > > In order to get to the meat of the job, I used Spring's > PathMatchingResourcePatternResolver to do the fancy classpath searching > stuff. So this implementation depends on spring-core for now (and therefore > commons-logging) but this is temporary. Implementing the classpath searching > myself is coming soon. > > The gem installation location is determined using the original gem methods. > This means that if JRuby is running from jruby-complete extracted to > USER_HOME/.jruby, the gems will be installed in there too. You can set > ENV['GEM_HOME'] to set another location. > > .gem files must be in the classpath under the path prefix /gems. These .gem > files can be in jars or directories in the classpath. They can't be in the > root because are issues searching for resources in the root of a classpath > that has both file system directories and jars. This originates from a > limitation in the JDK's ClassLoader.getResources method which only returns > file system locations for a passed-in empty String (indicating potential > roots to search). > > If we can figure out how to use Gem::Format.from_io to read from a > InputStream from a classpath resource URL, there are opportunities for much > slicker implementations that skip the initial step of extracting the .gem > file from the classpath. > > There are a couple ways to package this library for use. It doesn't make > sense to package it as a gem because of the obvious bootstrapping issues. I > think the thing to do is to include the jrubygems.rb script in the root of > the jrubygems jar file. If the jar is in your application's classpath you > would simply use it with: > > require 'jrubygems' > gem 'activerecord-jdbc-adapter' > > If this implementation turns out to be useful to the JRuby core, it could be > packaged with jruby-complete and required internally to extend RubyGems' > behavior for JRuby applications. This seems most desirable since it would > add classpath loading support for JRuby applications but not change the > behavior of regular Ruby applications at all. > > I'm looking forward to feedback. > > Alon > -- > View this message in context: > http://www.nabble.com/Proposal-for-managing-gem-dependencies-in-a-Java-%2B-JRuby-application-tf4946209.html#a14217742 > > Sent from the JRuby - Dev mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > -- Blog: http://www.bloglines.com/blog/ThomasEEnebo Email: [EMAIL PROTECTED] , [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
