jruby/jruby — pull request #1957 by mkristian (2014-09-07 08:21:14+00:00)
Title: removing LoadService#findLibraryWithClassloaders

the main idea is to reuse the current LibrarySearcher.

loading the kernel can be achieved by adding the root of the main classloader (the one which contains jruby-stdlib + jruby-core) to the LOAD_PATH

to expose ruby scripts inside required jar-files they just gets added to LOAD_PATH as well, using the jar:file: protocol

there are still some loose ends, also see travis:

* the old osgi support seems to work even less now
* gems from jars which are added to the classpath/classloader via java features (not via required 'my.jar') can not be found and/or do not work when they use something like Dir[ 'asd/*' ]
* some LOAD_PATH issue for 1.9 mode
* some loading issues with ruby scripts from jars or nested jars (ant test-extended)
* #1812 shows an inconsistency regarding requiring a jar with embedded gems.
* adding it to the classpath on the cmd-line works
* requiring it with -rmy.jar on the cmd-line works
* require 'my.jar' does not work

my thoughts about requiring jars and "adding them to the LOAD_PATH":
* a gem with java extension does not need this feature
* a java application using ruby scripting will add those jars with ruby files in the java way: as part of the classpath/classloader
* a project managed by bundler/jbundler will not need these or can easily avoid
* looking at jbundler where it is easy to have a bigger number of jars required which unnecessary bloats up the load_path and especially with using JarResource and its caching.

it would be nice if all those features would work the same for all the different environments:
* commandline
* jruby-complete
* j2ee
* osgi
* ....
but testing them only for the "commandline" case is not enough and nesting jars inside jars inside jars is problematic with more complex java frameworks.