Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
jrubycomplete - OSGi DynamicImport-Package breaks Adobe AEM #1977
I've built a bundle for Adobe AEM to compile SASS files on-the-fly, as part of the process I create a resource containing the sass gem using gems-in-a-jar approach which is then added to the bundle classpath. When a user requests a specific resource, the bundle creates an osgi scripting container and runs a small ruby script to generate the compiled css.
When the compilation phase takes place, the compilation will fail when sass attempts to include the date/datetime library as the dynamic import attempts to bring in joda-time.
Do we really need the DynamicImport-Package in the MANIFEST.MF?
changed the title
OSGi DynamicImport-Package breaks Adobe AEM
Sep 16, 2014
the DynamicImport-Package came in when I setup the following test cases
I will check if it is possible to remove it. but joda-time is needed for date/datetime implementation of JRuby. are you saying the dynamic import finds joda-time somewhere else ?
but be aware that the osgi scripting container is an orphaned piece of code and the more "LoadService" refactoring takes place the less is working, which was the case since jruby-1.7.12. the above test-cases are not using the osgi scripting container and my local branch can run those test-cases with the regular scripting container.
I will see if it is possible to reduce DynamicImport-Package to the crypto packages which caused the problems earlier.
Yes, joda-time is automatically deployed to the OSGI container when you run Adobe AEM via a bundle wrapper. When I previously looked at the Felix console, it was linking against this version when DynamicImport-Package was present. The bundled version by Adobe is relatively old as well so I suspect it wasn't very compatible (joda-time-1.6.jar).
If the "LoadService" is being heavily refactored, is the OSGi Scripting Container going to become deprecated, or is it just a case of catching up after the changes?
sorry I never indented to close the issue, I still want to give it trial to improve things.
yes, joda-time-1.6 will not work for jruby.
IMO I would deprecate it and remove it for jruby-9000. there is basically nobody to take care of it. there are no test-cases which could help keeping it alive, etc. and I focus on getting the regular ScriptingContainer to work out of the box OSGi, the current playground for this is the IsolatedScriptingContainer