replace javax.script export from scripting.api with servicemix bundle

[Justin Edelson <ju...@justinedelson.com>]

Currently, the scripting.api bundle exports javax.script by bundling the
contents of BSF's API JAR. 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?

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

Justin

Re: replace javax.script export from scripting.api with servicemix bundle

[Felix Meschberger <fm...@gmail.com>]

Hi,

On 23.01.2010 15:49, Justin Edelson wrote:
> On Sat, Jan 23, 2010 at 9:27 AM, Felix Meschberger <fm...@gmail.com>wrote:
> 
>> Hi,
> 
> ...
> 
>> 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.
>>
>  Hmmmm. Why embed javax.script in the scripting.api bundle?

What's the consequence of installing the service mix bundle ? What does
the bundle's Activator do ? (I have to admit, that I could not
understand what this is used for ....).

I see the advantage of having the API separate (it could just be omitted
on a Java 6 and higher platform) and upgrading our own API extensions
would not have an influence on "bare API" users.

Regards
Felix

Re: replace javax.script export from scripting.api with servicemix bundle

[Justin Edelson <ju...@gmail.com>]

On Sat, Jan 23, 2010 at 9:27 AM, Felix Meschberger <fm...@gmail.com>wrote:

> Hi,

...

> 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.
>
 Hmmmm. Why embed javax.script in the scripting.api bundle?

Justin

Re: replace javax.script export from scripting.api with servicemix bundle

[Felix Meschberger <fm...@gmail.com>]

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
>