<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 4/1/13 1:37 PM, Cantor, Scott wrote:<br>
</div>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750B06D2@CIO-KRC-D1MBX03.osuad.osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
Ok. That makes a lot more sense, but reinforces that us shipping an
ancient copy from a dead source is probably a bad idea.
</pre>
</blockquote>
<br>
Yes, I agree. I surmise (without really looking into it) that the
whole reason for existence for the scripting.dev.java.net stuff was
from a time when JSR-223 was new and both the scripting API
(javax.script.*) as well as the language-specific engines were a
separate effort from the actual language impls themselves. When
Java 6 shipped with the API built-in, that removed a lot of the
reason for it being a separate thing.<br>
<br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750B06D2@CIO-KRC-D1MBX03.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Even if we did, it seems clear we'd want to get them from the proper
sources. </pre>
</blockquote>
<br>
<br>
<br>
Absolutely. <br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750B06D2@CIO-KRC-D1MBX03.osuad.osu.edu"
type="cite">
<pre wrap="">I'm much more willing to consider that, but since I think the
engines are probably somewhat coupled to the language jars from a
versioning standpoint, that seems like a bad idea.
</pre>
</blockquote>
<br>
<br>
Yes, given the way things are now, shipping the engine is tantamount
to us shipping a particular version of the language, e.g. Groovy
2.1.2 rather than just "the Groovy engine". One question is whether
we should try and do that, as opposed to letting the deployer plug
in whatever version they want, and allowing them to upgrade the
scripting language impl on their own schedule, etc.<br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750B06D2@CIO-KRC-D1MBX03.osuad.osu.edu"
type="cite">
<pre wrap="">
And I think Peter's observation about jython was that even though we ship
jython-engine, that doesn't give you jython support until you add the rest
of the code, I guess. I had assumed the engines were self-contained, but
clearly not.</pre>
</blockquote>
<br>
<br>
Yes. I think the "old" situation is probably because of what I said
above, the engines were a separate effort from the JSR-223 people.
The "new" situation is that languages seem to themselves now supply
the (apparently relatively small) bits to adapt it to the JSR-223
API.<br>
<br>
And speaking of Jython -
<a class="moz-txt-link-freetext" href="http://wiki.python.org/jython/UserGuide#using-jsr-223">http://wiki.python.org/jython/UserGuide#using-jsr-223</a> :<br>
<br>
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
As of Jython 2.5.1 an implementation of JSR 223 is bundled in
jython.jar. Simply add jython to your CLASSPATH and ask for the
python script engine.</blockquote>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750B06D2@CIO-KRC-D1MBX03.osuad.osu.edu"
type="cite">
<pre wrap="">
So seems this is pointless for us to keep including in the current form.
</pre>
</blockquote>
<br>
<br>
Probably so. We don't need to ship the actual javax.script
framework JAR b/c it's in Java 6, and it's an open question as to
whether we ship any particular language impls. Assuming that the
other languages for which we formerly shipped engines are like
JRuby, Groovy and Jython, I think at the moment I'd lean towards
saying that we shouldn't, and just let the deployer add what they
want. It's literally just dropping some jars into the IdP's lib
directory before re-making the war.<br>
<br>
<br>
--Brent<br>
<br>
<br>
<br>
</body>
</html>