Hah, I've just noticed that my patch wasn't against the latest version of asdf-jar.lisp... I'll wait for some feedback before I spend more time on this, but I don't mind having another look at it. I'm definitely running the latest version:
TEMP> (lisp-implementation-version) "1.3.3" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_60-b19" "x86_64-Mac_OS_X-10.9.5"
On 24 November 2015 at 11:25, John Pallister john@synchromesh.com wrote:
Hello list,
I've been trying to use ABCL-JAR to package up my app for deployment to Google App Engine. I've come across a few issues; any comments would be appreciated. I've attached a patch to the ABCL-JAR:PACKAGE function that Works For Me(TM).
For the original code, see http://abcl.org/trac/browser/trunk/abcl/contrib/asdf-jar/asdf-jar.lisp?rev=1...
First, there was an issue where if the ROOT parameter is NIL the function would fail at line 90.
Second, The SYSTEM:ZIP function didn't want to nest JARs within the new JAR, so systems that depended on e.g. JSS via abcl-contrib.jar would fail. I filter out files in JARs on the assumption that one will just distribute those JARs along with the new one.
Third, my ASDF file includes a system that looks like:
(asdf:defsystem #:gabacle-clack-java :defsystem-depends-on (#:abcl-asdf) :version "0.1" :description "Java interface classes for Gabacle/Clack." :depends-on () :components ((:module java-src :pathname "src/" :components ((:class-file-directory "java")))))
This may or may not be good style, but it seems to be legal. When traversing the ASDF files, the class file directory component comes back with a PATHNAME-TYPE of :UNSPECIFIC, so I filter such entries out so that SYSTEM:ZIP doesn't object.
On a minor note, at http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/zip.java?rev=... "incorporation" is spelled "incoporation".
I hope this is useful. If people could point out where I've just got the wrong end of the stick, that would be great...
Cheers,
John :^P
John Pallister john@johnp.net john@synchromesh.com