On 11/29/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
Jesse Glick wrote:
> Peter Reilly wrote:
>> If the attribute is not specified a default path will be used - all
>> the scriptapi's that ant known about. - bsf, jsr.
>
> So why add the API attribute at all? Just do the right thing without
> having to be told. Legacy scripts will expect to use BSF and they will
> get it. New scripts wishing to use BSF can add it to the Ant classpath.
> The behavior of a clean Ant installation in a clean JDK 6 installation
> will be correct.
So if I have java6 then there's no way to get the javax stuff is bsf is
on the classpath. Dubious. i'd need some way of selecting an engine
exactly.
One may want to use the bsf javascript - it can use a more up-to-date
version of rhino that that in the used by javax.
The same ant build may want to use the javax javascript.
engine=bsf : bsf is mandatory
engine=javax: javax is mandatory
engine=auto :javax if found, fallback to bsf on older systems. (default)
This is my current thinking (except)
auto: bsf if found in the classpath, otherwise fallback to javax. (default)
the reason is that the user will have configured up bsf,
and every thing works, then update to java6 and the
script tasks stop working.
This may be a 1.7.1 level change, if its done with a new attribute and
not a new language string.
Maybe, but I would still like it for 1.7.0.
This gives us a chance to look at other
aspects of scripting, to make it more useful.
-better fault handing
-better default values
-ways of passing params to <scriptcondition> conditions (and for reuse)
These could be added in incrementally in the 1.7.* series.
One thing that is needed is evaluation support;
something like:
<property name="path" language="beanshell" eval='System.getenv("path")'/>
PS, script performance tests from the netkernel team:
http://www.mail-archive.com/jruby-devel@lists.sourceforge.net/msg01110.html
conclusion: use jython if you want speed.
Mmmm ...
jython has its own problems....
Peter
>
>> the 1.7.0 behaviour would be to find the first script manager in the
>> classpath and to use that one. Later versions of ant could check if a
>> particular script manager supported a particular language and use the
>> first that "reported" that it did.
>
> Why not just make that enhancement now? Shouldn't be complicated, right?
>
>> If asked for, future versions of ant could use custom defined script
>> managers - using a JAR service specification - or an ant task.
>
> The purpose of the JSR is to ensure that there is a standard for Java so
> that no one will need to create a new script manager in the future, and
> ideally that usage of BSF will monotonically decrease, so I hope Ant
> would not need to change its behavior again.
>
> -J.
>
---------------------------------------------------------------------
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]
