I think the use cases described above and the ones I'm interested in are quite different, so let me provide a bit of context.
I'm primarily interested (at least right now) in JRuby as a scripting language for use within Apache Sling (http://sling.apache.org). Without getting into too many of the details of Sling (although I'd recommend looking at it because we do some cool stuff ), Sling is a OSGi web application framework which is primarily concerned with taking "resources" from a "repository" and transforming them to serve user requests. This transformation is generally (although not exclusively) done via scripts. We currently "ship" custom ESP and JSP implementations (albeit heavily based on Rhino and Jasper respectively) along with Groovy support (using the groovy jar). JRuby, Velocity, Scala, and Freemarker are all available as add-ons (I'm probably forgetting something). In short, we expect to be able to support any JSR-223 implementation, provided that the implementation is "OSGi-friendly".
Note - here I'm using "we" to refer to the Sling project. But to be clear, this request isn't being made on behalf of anyone but me.
In a Sling applications, scripts are not tied to a particular bundle - they are generally hosted in the repository (scripts are resources too!). The dependencies of these scripts aren't knowable at build time. When a script executes, it should have access to any exported package from any bundle in the OSGi framework (ignoring OSGi security...). Likewise, when a script executes, it shouldn't have access to any non-exported packages except for any internal classes used by the script engine (i.e. JRuby in this case).
Leaving aside the specifics of Sling for a minute, this seems like a pretty reasonable use case for scripting in general. You simply can't expect the "imports" of a bundle using scripting at build time to be defined. And even if they could be defined at build time (i.e. you had a set of scripts which were resources within a bundle), it's not like Bnd can figure out that your bundle needs to import "builtin.javasupport" (unless you pre-compile, which is a different story entirely).
For our ESP and JSP implementations, we have a custom classloader which, in essence, emulates the behavior of Dynamic-ImportPackage: *. For Groovy, we simply use the JSR-223 implementation provided by the Groovy JAR. I would like to be able to do the same thing with JRuby.
So... let's talk specifics. There are really two primary things I want to be able to do with JRuby in Sling:
1) I want to be able to write a basic script which just uses Ruby/JRuby builtins.
2) I want to be able to write a script which 'requires' one or more gems where those gems are being provided by a bundle.
Plus, one more general thing:
- I want to be able to write some Java code which runs a Ruby script which creates a new object which implements a Java interface where that interface is exported by a bundle. Subsequently, I want to be able to register that object in the OSGi service registry, but that has nothing to do with JRuby (in the future, some kind of DSL for this would be interesting, but that's not my concern right now).
AND... I want to be able to do these things without having JRuby installed on the server. In my prior testing (with 1.5.6), in order to run even the most basic of scripts, JRuby had to be installed and the jruby.home system property set. In 1.6.0.RC1, I can now run a basic script without having jruby.home set. Great progress. I also want to be able to do all of these through a JSR-223 interface. And I would definitely prefer if this was just doable with the jruby-complete JAR.
I expect all of these to be possible by adding Dynamic-ImportPackage: * to the manifest and I don't see any of them being possible any other way.
I have no argument with
JRUBY-5384, I just don't think it fits my needs. I'm uninterested in reimplementing JRuby's JSR-223 implementation just so I can use OSGiContainer instead of ScriptingContainer. I would rather that the JRuby bundle's classloader behave the way I think a scripting container is expected to behave ("require-lazily anything-you-need-as-long-as-the-fully-qualified-java-name-is-written")
The notion inside a script to have
is interesting, but I think it's a bad practice to embed bundle names like this in code of any sort. A good part of the power of OSGi is that the provider of a package is flexible. That's why Import-Package should generally be preferred to Require-Bundle.
Finally, the notion of a fragment bundle is doable, but I really would rather jruby-complete had this itself. Again, call me lazy, but I'd prefer not to have to maintain this fragment.
I've posted a few integration tests to https://github.com/justinedelson/jruby-osgi-testing and will be adding more. I'm really happy that JRuby now doesn't require that it be installed to be used in an OSGi context.
It's been a while since I was on jruby-users, but I can rejoin if that would be a good context to have any further discussions along these lines.