removing LoadService#findLibraryWithClassloaders

[mkristian]

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)
• Gems in a jar can't be required from code #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.