On 19/05/2010, Rony G. Flatscher <[email protected]> wrote: > On 19.05.2010 17:18, sebb wrote: > > Following on from https://issues.apache.org/jira/browse/BSF-32: > > > > I'm not sure it really makes sense to include a single jar with all > > the BSF engine factories in it. > > > > For one thing, why would one want so many factories present? > > > > To be "future safe", such that one scripting language is used, but > later, one may want to try out another one concurrently without a need > for a JSR-223 engine being available for that scripting language > (because one must use an older version for whatever reason).
The factories are useless without the engines, so I don't think BSF helps here. Note that bsf-engines.jar is badly named - it contains engine factories only, not engines. > OTOH, Java 6 is around for a couple of years already and therefore most > of the maintained Java-related scripting languages would probably supply > a JSR-223 engine in their distribution already. If the bsf-engine bundle > and/or the individual JSR-223 engines remain downloadable separately > from BSF-3, then there should be no problem whatsoever. Yes, the code for each factory (and each engine) is separately available (outside the ASF). > > > They will only work if the corresponding engine jar is also present, > > so most of the factories will fail at run-time. > > > > Another problem is the possibility of clashes between factories for > > different versions of a scripting language. > > > > This seems to be some sort of a show-stopper currently. AFAICT it's only a showstopper because of bsf-engines.jar. And the same problem applies to Java 1.6 when used with bsf-engines.jar, because bsf-api by design implements the javax.scripting API which is now in Java 1.6. > (Actually it should not be a show-stopper but be able to deal with > different engine versions, but with the same name. Then one could query > the engine what capabilities it has and pick the more powerful/more > versatile or the latest one.) I agree that the selection criteria are not ideal, but that is what the JSR-223 API currently mandates. JSR-223 does not allow one to select by engine version, only by extension, mime-type and name. One can get the full list of engines, and it would be possible to put some code in bsf-utils to make use of that to provide version-specific engine selection. But that is outside the scope of JSR-223, and would not be a "standard" API. In the meantime, one just has to ensure that the factories that are available on the classpath don't contain incompatible engines. > > > The BSF3 code is still useful for Java 1.4 and Java 1.5, and the > > bsf-utils jar can be used with Java 1.6+ as well. > > > > == > > > > I'm also not sure that the specific engine test cases add much value - > > any failures I've seen are nothing to do with the BSF api code itself, > > but all about how the test classpath is set up. > > > > I think one could keep one or two of the test modules only. > > These should probably depend directly on the specific engine factory > > rather than on the bsf-engine bundle. > > > > +1 > > Thoughts? > > > I think it would be o.k. to leave the bsf-engine bundle out of the BSF3 > distribution, but allow the bundle and the individual JSR-223 engines to > be downloaded separately, such that older versions of those scripting > engines that have no JSR-223 engine on their own can still be deployed > with BSF3. My point is that the factories (and engines) all originate outside the ASF. The engine bundle is an aggregation of some of the available engines factories. [It's badly named too, as the engines are not included!] So I think the bundle just complicates the build, without offering any benefit. > Reasoning: quite a few commercial deployments will have to live with the > company's politics regarding upgrading software and versions to be > deployed, such that this scenario will materialize one way or the other > (never change a running software/configuration). For them being able to > get bsf-engine bundle (or the individual engine) will help a lot, if > they wish to use JSR-223 scripting on pre-Java-6 installations. I think the engine (factory) bundle will be just as much a nuisance for commercial deployments, because of the problem of version clashes. And commercial deployments still have to go elsewhere for the actual engines, without which the factories jar is useless. > ---rony > > > --------------------------------------------------------------------- > 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]
