Scripting engines in V2 distribution

[Brent Putman]

On 3/31/13 9:48 PM, Cantor, Scott wrote:
>
> My discomfort with the scripting jars is that they don't have any sort of
> active development or official release status behind them.

I was curious about whether this is really the case, since I know that
at least some of those languages (JRuby, Groovy) are very actively
maintained projects and widely used.



>
> We could leave things be for 2.4 and just pull them in V3, or we can pull
> them for 2.4 and just get it over with. The impact is that anybody using a
> non-default scripting engine would just be responsible for going and
> getting/building the engine they think is still viable to depend on (I
> would personally claim none of them are based on my observations, but
> perhaps I'm wrong).



I was basically just wondering/suspecting if perhaps support for the
various language-specific engine code had moved elsewhere, for example
shipping with the languages themselves.  I found this [1] for Groovy,
which suggests that the JSR-223 engine is now just a part of the 
standard Groovy distribution. It says there:



> To make this example work, if you're running Groovy 1.5.x, add
> |groovy-engine.jar| from https://scripting.dev.java.net/ to your
> CLASSPATH and run this program using Java 6. But since Groovy 1.6,
> Groovy already contains the groovy scripting engine compliant with
> JSR-223.


The latest version of Groovy 2.1.2 does seem to have this support in
their 'groovy-jsr223-2.1.2.jar' which contains what (I would think) are
the expected classes, based on their names.

Tracking down JRuby was a little harder, but I did find their Jira issue
[2] where they discussed this, and it looks like they did the same.  The
JRuby source tree and jruby.jar binary does seem to have the expected
content, including the Services API declaration for
javax.script.ScriptEngineFactory.

I haven't looked at any of the others, but I wouldn't be surprised to
find a similar situation.  So scripting.dev.java.net may be dead, but
that may just be because the support has moved to the languages themselves.

Now, whether we should start and/or continue shipping any of the
particular languages/engines in the IdP, as opposed to asking the
deployer to install what they want, is another (and different) question.




[1]  http://groovy.codehaus.org/JSR+223+Scripting+with+Groovy
[2]  http://jira.codehaus.org/browse/JRUBY-3687

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20130401/1a2cd91a/attachment.html