Attached is a patch that allows LOAD to work on arbitrary JAR files. It uses the semi-official ([according to Wikipedia][1] and as implemented in java.net.URL) URI Schema:
jar:file:PATH!/JAR_ENTRY
where "file:PATH" is a filepath URI (meaning that absolute pathnames need to have a double leading slash, i.e. '//var/tmp/foo.jar'), and JAR_ENTRY is the path in the jar file.
I never could get Eric Marsden's patch to work, as it would load the initial FASL entry (the one ending in '._' containing the load instructions), but not the compiled classes. It bothers me a little that following his instructions
Next steps:
1) making this work for JARs containing "foo.abcl" zipped FASLs which are themselves zipped collections of a single FASL (ABCL overloads the ".abcl" suffix to mean either a initial FASL OR a zipped collection of the initial FASL plus associated compiled toplevel forms). Such zipped FASLs would be the natural unit for dealing with ABCL compile artifacts, right?
2) Developing packaging utilities for putting together compilation units. This would probably not be so necessary if step 1) can be made to work, right?
3) Check how this works under Microsoft Windows.
Question:
A) There probably should be some way to load all the FASLs contained in a JAR. Would
(load "jar:file:foo.jar")
work as a syntax with the semantics of loading all the compiled classes that one can find in the associated JAR?
B) I have deviated a little from Eric's original idea to bundle additional classes with the current abcl.jar for distribution, into having additional JARs with the extra classes. If anything on the path that I am going does not meet up with use case expectations, please let me know.
Bugs:
I) Currently the code has a bug that if a file whose name is a duplicate of one in the initial abcl.jar, it will not be loaded.
[1]: http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes