(some) classloaders do not see the default gems and can not update/downgrade those gems

[mkristian]

some (or all) osgi classloaders and some j2ee classloaders do not work with rubygems at all. the reason is that rubygems needs to "browse" the directory structure to find the specifications/* or the specifications/default/* - a classloader does not offer such an API for doing so. i.e. there are NO installed gems and there are NO default gems with jruby coming from such a classloader !

what I did with OSGi is to unwrap the gems, i.e. copy the "lib" directory of gem into the root of the jar (gem-maven-plugin has such feature now). that helps until now.

BUT the default gems logic only works if those specifications/default/* can found otherwise you can not "overwrite" for example jruby-openssl, since these files will be just treated as regular files of the stdlib.

a possible solution would be to stdlib without those default gems bundled but with dependencies towards those default gems. dito with jruby-jars having a stripped jruby-stdlib with explicit deps of default gems would help warbler - not sure about ruboto's use of jruby-jars

[mkristian]

just had a trial with removing all the jossl from jruby-stdlib and "install" jossl. that setup worked with websphere - websphere can NOT load those jar from within a jar ! since all nested jars are coming from gem, the stripped jruby-stdlib will help.

[mkristian]

there are classloaders (OSGI or some j2ee classloaders) where directory globbing does not work. this means it is already difficult to embed gems in jar/war which works with those classloaders - the trick is do something similar what bundle install --standalone does: setup the load_path manually.

but we the default gems remain a problem since inside those classloaders rubygems can NOT find the files in META-INF/jruby.home/lib/ruby/gems/shared/sepcifications/default/ . i.e. it is the exact same situation is in #1706

well let's look at our artifacts:
jruby-dist : guess no need to change anything here
jruby-complete : the name says it is complete - nothing to change here
jruby-core : can stay as is
jruby-stdlib/jruby-stdlib-complete : they are exactly the same - I tried to modularize it before and gave up
jruby-jars : uses jruby-stdlib-complete but would be easy to to just add these default gems as dependencies in the gemspec. that would work with warbler, bundler, etc
jruby/jruby-noasm : they could stay as they are - maybe it is worth dropping one

the actual change is rather small:
jruby-stdlib : is the one without default gems embedded but declared - let the gems/shared/specifications/default/*gemspec remain to prevent gem uninstall on those
jruby-jars uses jruby-stdlib and also declares the default gesm explicitly
jruby/jruby-noasm : will depend on jruby-stdlib-complete to remain as they are.

to declare gem dependencies in jruby-stdlib those gems needs to be on oss.sonatype.org - a while ago I asked them if it is possible to deploy gems on maven central:
https://issues.sonatype.org/browse/OSSRH-9565
if we they allow this only for our gems, that is good enough (jossl is the driving force in all this). for this sonatype issue I would need @enebo, @headius username on sonatype.org to round this up. pushing gem snapshots to sonatype is really hacky right now and would become straight forward if we can push our gems to group_id rubygems.

the jruby-stdlib will be build in lib/ and maven/jruby-stdlib can go away. in the end we get on less maven module ;)

regarding OSGi this is only a partial solution - it works when you add jruby/jruby-noasm to your bundle and trick a little when embedding gems into your jar. but it does not help with jruby-complete which is also an OSGi bundle

I can provide integration-tests for the OSGi case which most probably ensures that this "feature" will work on any j2ee classloader as well.

/cc @ratnikov

[mkristian]

just wanted to add some more after a discussion with @ratnikov

the default gems issue I see especially on websphere especially indeed be just LOAD_PATH problem which is caused by jruby-rack (I am already using a patched jruby-rack since it plays around to much with CWD, GEM_PATH, LOAD_PATH and maybe other things)

with OSGi I have classloader which does not use URLClassloader BUT where there is NO fiddling on the ruby side of things. and it is easy to setup integration tests for it - we have already one testing that openssl at least loads (since 1.7.11 or so). if OSGi works then a war-file should also work since a war-file is just a jar where the classes are located in /WEB-INF/classes instead of /

[mkristian]

jruby-stdlib will add extra directory listing info:c04c50f#diff-94623248443d235e4cf2485d3fcc240aR77