Hi everyone,
just had the first working day at the University as after the Con I went
to Scotland on family business for more than a week...
Sanka Samaranayke wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kev Jackson wrote:
Hi,
When bsf is shipped, will there be a default scripting language
shipped with it? The reason I ask is that to refactor the bsf
build.xml file I'd like to use a scriptdef and javascript, I can
get this working now, but obviously this is of no use if bsf itself
requires an extra scripting library to be built!
To refactor the bsf build.xml to DRY, I can use a <scriptdef>
instead of the horrible <antcall> structure currently available.
As bsf is a script friendly tool, it makes some sense to use
<scriptdef> in the building of bsf. So I guess that for
building/testing bsf, a scripting language lib is required (like
js.jar for example), this would make bsf dependent on a 3rd party
product for building itself.
Now, I can build bsf with the newly refactored build.xml using
javascript, so long as I make javascript available to ants
classpath. Is this ok or not - please give feedback.
AFAIK, Mozilla license is compatible with Apache license and I am ok
to have javascript as the default scripting language shipped with bsf.
Since bsf is essentially a framework for scripting, it would be nice to
have a default scripting language that it will always support.
Anyway we need to get the consensus of others to make this happen
and I would suggest that you continue refactoring the build.xml
making javascript available in ants classpath since this proposal
would most likely be accepted.
Would have no objections of creating a distribution which contained
Rhino/Javascript if it is legally o.k. w.r.t. licenses. Though we
usually have Javascript already on machines that use Rhino for the
browsers.
At the moment I deploy BSF by copying the BSF jar to the jre/lib/ext
directory. The reason being, that any class in any jar in that directory
will be available to Java and therefore needs not be put on the
CLASSPATH. By the infrastructural nature of BSF it is clear, that
eventually every Java application could take advantage of Java scripting
via BSF. Therefore it looks to me to be a "natural" extension to the
Java language per se.
However, this may cause problems where BSF depends on other jars like
commons-logging. It is possible, if not likely, that some version of
commons-logging is present already, hence the BSF installation
needs/must not supply the version it uses. OTOH over time it is possible
that some Java application uninstalls and uninstalls its version of
commons-logging from the jre/lib/ext directory as well, causing BSF to
not run anymore. Don't know whether creating a *sealed* jar would allow
for using BSF with a bundled commons-logging independent of a standalone
or additional commons-logging in the jre/lib/ext directory. (If anyone
has experimented with this configuration and sealed jar's it would be
nice to step forward and give us some hints.)
---
Having said that, I would suggest to create two distribution jars, one
with the "naked" BSF, and one with BSF+commons-logging and perhaps with
Rhino bundled with it. The latter allowing one to merely point to one
jar only in the CLASSPATH.
Of course, I would prefer a solution in which one could reliably deploy
BSF as an extension to Java, relieving the burden from anyone else
wishing to take advantage of BSF scripting. This has been achievable
already since Java 1.2 by copying the jar to jre/lib/ext.
HTH a bit...
---rony
