Hi, On 22.01.2010 17:02, Justin Edelson wrote: > Currently, the scripting.api bundle exports javax.script by bundling the > contents of BSF's API JAR.
Yes, to be able to support Java 5 runtimes which do not have the javax.script API embedded, Java 6 comes with it. > However, ServiceMix provides a bundleized version > of javax.script > (org.apache.servicemix.specs:org.apache.servicemix.specs.scripting-api-1.0). > Would anyone object to me removing the BSF stuff from scripting.api and > scripting.core and using the ServiceMix bundle instead? IIRC scripting.core has just an import on the javax.script packages. It just contains the ScriptEngineManager supporting dynamic addition and removal of script engines. It is the scripting.api bundle, which exports javax.script package. > I ask because I ran into essentially the inverse of SLING-217: code written > using the generic version of javax.script.Bindings wouldn't compile against > the BSF version. This shouldn't be the case with the ServiceMix bundle (and > the bootclasspath stuff added to fix SLING-217 can be removed). AFAICT the difference between the ServiceMix bundle and the BSF version is, that former is "genericized" as is the Java 6 version, while the BSF version is non-generic, since it is written against Java 1.4. So, from my POV, it would be a good option to replace the BSF javax.script package with the ServiceMix version and thus be able to remove the boot class path hacks. Ergo, embed the javax.script package from the ServiceMix bundle in the scripting.api bundle. But I would like to keep the stuff we do around the ScriptEngineManager in scripting core. So from a usabilty POV, this makes it easier to develop and from a maintainence POV it makes not difference, its just a bundle update of the scripting.api bundle. Regards Felix > > Justin >
