Add DynamicImport-Package to OSGi manifest

Is there any down side to adding this? I don't know OSGi well.

The DynamicImport-Package-Header is the last line of defense and should only be used when there are no other options. The Header defines that if at runtime a class must be loaded whose package is not specified via Import-Package then it will be searched in all available bundles. You can not specify the version of the dynamically imported package. But for JRuby which executes scripts with unknown imported java packages, using this Manifest-Header is the only OSGi-implementation-independent way of preventing a ClassNotFoundException. With Equinox another solution is using Buddy-Classloading.

The Groovy project solved this issue with DynamicImport-Package too, see GROOVY-3192.

Adding that DynamicImport-Package to the JRuby jar's MANIFEST.MF would allow the JRuby jar's class loader to access any (Java) package exported by any other jar file in the OSGi container. However, once a linkage is established between the JRuby jar and some other jar, it is permanent. No other script, running in the context of the JRuby jar's class loader, will be able to access any other version of that package from any other jar file.

That limitation is problematic in the enterprise OSGi environment, where you could have several JRuby applications deployed to an OSGi container and multiple versions of library jars floating around. The only workaround that I can see would be to have multiple copies of the JRuby jar, under different names and versions, and associate one copy with each application.

DynamicImport-Package is bad OSGi practice because OSGi is a module system, and rather than declaring a dependency on a specific version of some specific (Java) package (or jar file; that can be done either way), it indicates a dependency on anything, and those dependencies are only determined at runtime.

I think that any usage of DynamicImport-Package in the JRuby jar file could better be done by having the proper Import-Package or Import-Bundle in the application, and making sure that any JRuby scripts run in the context of the application's class loader. It works fine for JRuby on Rails applications built using Warbler. Also, there has been some recent discussion on the jruby-user mailing list recently, in the context of the JSR 223 scripting engine; I cannot link to the archive at the moment, but the subject is "running jruby in an osgi container".

Ah, there it is.

The thread on jruby-user starts with:

http://archive.codehaus.org/lists/org.codehaus.jruby.user/msg/4A539DEE.8010102@trialox.org

+1 to everything Tommy explained.

org.jruby.embed.osgi.OSGiScriptingContainer contributed in JRUBY-5384 is probably a good solution to the use case described: instead of having to resolve all the objects of the bundle from the thread's context-classloader, the classloader of the bundle can be added to the instance of the OSGiScriptingContainer itself.

JRUBY-5414 has a more detailed explanation about this.