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".