jakarta-bsf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Adams <je...@wolfram.com>
Subject Re: Breakout of language engines
Date Wed, 11 Dec 2002 19:24:28 GMT
At 2:02 PM -0500 12/11/02, Sanjiva Weerawarana wrote:
>"Jeff Adams" <jeffa@wolfram.com> writes:
>>
>>  Once Languages.properties goes away, will we also change it
>>  so that instead of one bsf.jar file we build
>>
>>  bsf.jar    with optional builds of:
>>  bsf-engine-javascript.jar
>>  bsf-engine-jython.jar
>>  etc... each with their own
>  >    META-INF/services/org.apache.bsf.BSFEngine?
>
>We used to build and dist BSF this way a long time ago (I'm
>thinking back to v1.0 timeframe now). However, we soon found
>this to be a PITA as one had to keep adding (very) small jars
>to one's classpath. Secondly, just having the BSFEngine impl
>isn't enough to have access to the language of course; one
>also needs the actual language runtime.

That seems reasonable enough to me.

>  > I would think this would make it easier to build and deploy
>>  only engines one is interested in and allow drop in
>>  support for additional engines as needed,
>>  especially with use within ant.
>
>IMHO the better way would be to try to get the language
>implementors to take over and own the BSF integration code.
>That way the model is like JAXP .. the JAXP project builds
>the core and compliant implementations bridge themselves to
>the core. If BSF had a dynamic discovery mechanism ala JAXP
>then this approach would work very nicely.

I agree with this, which I believe is consistent with the SPI,
META-INF/services/org.apache.bsf.BSFEngine technique of
dynamic discovery which JAXP and other Apache projects use.

I have no problem with keeping the single bsf.jar which includes
all the jakarta-hosted engines, I was just thinking if
the new dynamic discovery would support all engines
to be external to bsf.jar why not make that clean separation?
Doesn't JAXP also separate any implementation of things like
the parsers from the core API as separate jars too?

I wondered also in the context of developers who build bsf from source,
is there a clean way to easily select engines to build using the ant
build scripts just
to save people from having to get failures if external jars aren't
also grabbed that are needed for each of the individual engines

As long as one can just drop in another jar to add an additional engine
to an app that uses bsf and we get the dynamic discovery, I won't 
mind if the default engines aren't
separated as that is somewhat of secondary importance if I had to choose.

Thanks,
Jeff

Mime
View raw message