On 8/27/09 6:33 PM, Alessio Stalla wrote:
Greetings all,
I have downloaded the 0.15 release of abcl from the official site, to use it in a side-project at work. I found out that the archive does not contain the src/org/armedbear/lisp/scripting directory, where the JSR-223 stuff resides. Worse, the archive does contain the META-INF/services/javax.script.ScriptEngineFactory, so when built the jar actually declares it contains a JSR-223 implementation, but it does not. How is the archive built? I think I saw tasks in the Ant-based build file to zip the source, maybe those don't include the scripting/ directory. If that is the case, I can fix it for build.xml. I don't know how the Lisp based build works, though.
Ant-based, aka build.xml, is the way we build releases, as far as I know, as the Lisp based build currently doesn't have the necessary features. It makes sense that we use a build process that is reproducible by developers, by adding some verification steps to build.xml, so we can all test the results.
From examining 'build.xml' (i.e. without testing) it appears that using these source targets on Java5 will falsely include the 'META-INF/services/javax.script.ScriptEngineFactory' in the JAR even when compiling in the absence of JSR-223 support. So, I think the abcl-src-0.15 release was made with Java5, which would explain this behavior.
If we can confirm that using a JSR-223 enabled abcl.jar doesn't cause any problems running in Java5 without JSR-223 classes present, we can just ship these classes with future releases. I think the references to JSR-223 from the org.armedbear.lisp package are all soft (i.e. there are no direct references in Java), so there should actually be nothing that breaks Java5 with such a release such as "Class not found errors" as long as nothing tries to use the JSR-223 code. We have to test this, and maybe Alessio can give some feedback.
We should probably then
a) fix 'build.xml' to not include any scripting artifacts when compiled with java5 in the absence of JSR-223
b) change the source archive targets to complain if Java6 is not used to make a release
c) use Java6 to make a release
d) Test that this release works in both Java5/Java6