Re: Ideas on support of javax.script'ing
On Fri, 27 Oct 2006, Peter Reilly [EMAIL PROTECTED] wrote: The idea is that ant-core code would first check for the language implementation in bsf and if that (the language or bsf) does not exist, ant-core will then check for javax.script support for the language. Sounds good. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ideas on support of javax.script'ing
I have been thinking on how to support javax.script in future
versions of ant.
Initially, I though of using a new task scriptx or something
similar, but have reconsidered and now think that the same
tasks (script, scriptdef and types scriptmapper etc) can
be used.
The idea is that ant-core code would first check for the language
implementation in bsf and if that (the language or bsf) does not
exist, ant-core will then check for javax.script support for the language.
This would mean that using jdk6, ant would support javascript
out-of-the-box, but users would be able to use non-cut-down
versions of rhino by installing bsf and rhino, either in -lib places
($ANT_HOME/lib, ${user.dir}/.ant/lib) or by using the
classpath element of script.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ideas on support of javax.script'ing
On 10/27/06, Peter Reilly [EMAIL PROTECTED] wrote:
I have been thinking on how to support javax.script in future
versions of ant.
Initially, I though of using a new task scriptx or something
similar, but have reconsidered and now think that the same
tasks (script, scriptdef and types scriptmapper etc) can
be used.
The idea is that ant-core code would first check for the language
implementation in bsf and if that (the language or bsf) does not
exist, ant-core will then check for javax.script support for the language.
This would mean that using jdk6, ant would support javascript
out-of-the-box, but users would be able to use non-cut-down
versions of rhino by installing bsf and rhino, either in -lib places
($ANT_HOME/lib, ${user.dir}/.ant/lib) or by using the
classpath element of script.
This sounds like a reasonable scheme Peter. Although I think I'd also
want to be able to force the use of scripting engine thru the JDK, if
that's technically possible.
--DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ideas on support of javax.script'ing
On 10/27/06, Dominique Devienne [EMAIL PROTECTED] wrote:
On 10/27/06, Peter Reilly [EMAIL PROTECTED] wrote:
I have been thinking on how to support javax.script in future
versions of ant.
Initially, I though of using a new task scriptx or something
similar, but have reconsidered and now think that the same
tasks (script, scriptdef and types scriptmapper etc) can
be used.
The idea is that ant-core code would first check for the language
implementation in bsf and if that (the language or bsf) does not
exist, ant-core will then check for javax.script support for the language.
This would mean that using jdk6, ant would support javascript
out-of-the-box, but users would be able to use non-cut-down
versions of rhino by installing bsf and rhino, either in -lib places
($ANT_HOME/lib, ${user.dir}/.ant/lib) or by using the
classpath element of script.
This sounds like a reasonable scheme Peter. Although I think I'd also
want to be able to force the use of scripting engine thru the JDK, if
that's technically possible.
Everything is technically possible ;-)
I was thinking of using language=bsh:javascript or jsr:javascript
to allow the
user to force one or the other, however, having bsf.jar and js.jar in
the $ANT_HOME/lib, is a user's choice, so if they are there it is
a good assumption that the user wants to use them.
Peter
--DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ideas on support of javax.script'ing
Peter Reilly wrote: [...] however, having bsf.jar and js.jar in the $ANT_HOME/lib, is a user's choice, so if they are there it is a good assumption that the user wants to use them. I think that Groovy has native jsr support but jruby didn't last time I checked (though that may soon or may have already changed) so I might want to go with native jsr when using Groovy even though I have bsf.jar in my classpath for when I want to use jruby. So, the 'bsf:', 'jsr:' switch sounds good to me. Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ideas on support of javax.script'ing
On 10/27/06, Paul King [EMAIL PROTECTED] wrote: Peter Reilly wrote: [...] however, having bsf.jar and js.jar in the $ANT_HOME/lib, is a user's choice, so if they are there it is a good assumption that the user wants to use them. I think that Groovy has native jsr support but jruby didn't last time I checked (though that may soon or may have already changed) Support for jruby is provided via the java scripting project: https://scripting.dev.java.net/ They have a number of engines for various languages that do not have native implementations. (provided as language engine jar files). Peter so I might want to go with native jsr when using Groovy even though I have bsf.jar in my classpath for when I want to use jruby. So, the 'bsf:', 'jsr:' switch sounds good to me. Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ideas on support of javax.script'ing
Peter Reilly wrote: On 10/27/06, Paul King [EMAIL PROTECTED] wrote: Peter Reilly wrote: [...] however, having bsf.jar and js.jar in the $ANT_HOME/lib, is a user's choice, so if they are there it is a good assumption that the user wants to use them. I think that Groovy has native jsr support but jruby didn't last time I checked (though that may soon or may have already changed) Support for jruby is provided via the java scripting project: https://scripting.dev.java.net/ They have a number of engines for various languages that do not have native implementations. (provided as language engine jar files). Peter Cool. I didn't remember the list being so complete last time I looked. I guess the question still remains. If I needed BSF for e.g. NetRexx would I want BSF or JSR for everything else? I suspect I would be going JSR if I could. Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
