On Dec 15, 2010 8:41 AM, "Ketan Padegaonkar" <ketanpadegaon...@gmail.com> wrote: > Hi, > > Here's what I've done. You may checkout http://swtbot.org/tools/ for > the final look and feel of the console. > > * Use jruby's manifest AS-IS > * Create another bundle(https://gist.github.com/742000) that: > * can manage creating and disposing of jruby runtimes > * Does a "DynamicImport-Package: *" in the MANIFEST.MF(evil!) - > https://gist.github.com/742000 > * Uses the plugin's classloader when creating the jruby runtime - > https://gist.github.com/742003 > > "DynamicImport-Package: *" is a very evil thing to do in the OSGi > land. However my requirement at the time was to create an eclipse > console that allowed eclipse/OSGi developers to try out different > things in a jruby console with access to all the apis. > > In your case, you may choose to import only those packages that you > are interested in.
If you don't change the manifest, I assume you're requiring the builtin folder (and other ruby/jruby libs) to be installed on the local machine in order for require 'java' to work. If I'm wrong in that, and you have a way to load the .rb files embedded in jruby-complete.jar without modifying jruby-complete.jar's manifest, I'd like to hear about it. All in all, the DynamicImport-Package declaration is certainly another way to go, but I'd prefer to have JRuby support an optional explicit classloader for loading Java classes from names. I have poked around a little more at my patch (though nothing's pushed to github yet) because I don't want to introduce leaks by holding hard references to other bundle's classloaders in a given runtime, but I'm still interested in hearing from those more familiar with JRuby internals on the overall approach I'm taking.
