jakarta-bsf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher" <Rony.Flatsc...@wu-wien.ac.at>
Subject Re: distribution question
Date Mon, 28 Aug 2006 19:39:17 GMT
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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message