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.

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

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 /

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