The problem surfaced with what seems to me to be a regression in the use of the abcl-binary-locations system, which puts compiled files in separate directories according to implementation. I'm working on packaging up my application in a single jar. I move the systems inside the jar and then try to load using asdf. Because of the use of :relative, the call to OUTPUT-FILES-USING-MAPPINGS duplicates the leading directory components, and then the compiled file is not found.
The thing is that with the current setup has it that there is never an :absolute directory. I think this will violate assumptions of programs beyond abcl-binary-locations. I believe the assumption will be that truename will give you something that has an :absolute pathname.
-Alan
CL-USER(37): (asdf::oos 'asdf::load-op (asdf::find-system "jss")) 0: (ASDF::OUTPUT-FILES-USING-MAPPINGS #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.lisp" (#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") NIL) 1: (ASDF:IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME) 1: IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME returned "armedbear-0.19.0-dev-darwin-unknown" 0: OUTPUT-FILES-USING-MAPPINGS returned (#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl") 0: (ASDF::OUTPUT-FILES-USING-MAPPINGS #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.lisp" (#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") NIL) 1: (ASDF:IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME) 1: IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME returned "armedbear-0.19.0-dev-darwin-unknown" 0: OUTPUT-FILES-USING-MAPPINGS returned (#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl") 0: (ASDF::OUTPUT-FILES-USING-MAPPINGS #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.lisp" (#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") NIL) 1: (ASDF:IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME) 1: IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME returned "armedbear-0.19.0-dev-darwin-unknown" 0: OUTPUT-FILES-USING-MAPPINGS returned (#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl") 0: (LOAD #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl") Debugger invoked on condition of type FILE-ERROR: File not found.
On 3/11/10, Mark Evenson evenson@panix.com wrote:
On Mar 11, 2010, at 9:37 AM, Alessio Stalla wrote:
[…]
If you look at the contents of a jar file via java.util.ZipFile.entries(), all the hierarchal entries do not have an initial slash, so are best expressed as relative pathnames.
True, they don't have an initial slash, but they're all relative to the root of the jar i.e. they are absolute, to my understanding. If they were relative, they could be interpreted differently depending to some reference directory.
Since we control the behavior of Pathname completely as a Java primitive, we can change the underlying implementation to properly treat the :ABSOLUTE component of the DIRECTORY list by special-casing the searching/iteration of jar file contents. This change would preclude the distinction between a JAR that has entries with an initial '/' and those without, but we could pave over those differences via some amount of if/thens sprinkled throughout the code.
But before digging everything up again and testing it, I'd like to understand what we want to accomplish here.
Since MERGE-PATHNAMES currently has special semantics with jar pathnames already, we wouldn't really gain any useful behavior that I can immediately think of.
Would you propose that the namestring of a jar pathname remain "jar:URL!/foo/bar.lisp" or would it now become "jar:URL!//foo/bar.lisp" (which would break the behavior documented in java.net.JarURLConnection)?
So, if y'all really want to change the :RELATIVE to :ABSOLUTE here, please convince me, as I currently a net negative in this approach.
I've updated [the Pathname implementation notes][1] to explain the current behavior better.
--
"A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."