source: trunk/abcl/doc/design/pathnames/abcl-jar-url.text @ 12422

Last change on this file since 12422 was 12422, checked in by Mark Evenson, 14 years ago

Extensively reworked new implementation for specifiying jar pathnames.

Pathname namestrings that have the form "jar:URL!/ENTRY" now construct
references to the ENTRY within a jar file that is located by URL. The
most common use is the "file:" form of URL
(e.g. 'jar:file:/home/me/foo.jar!/foo.lisp') although any valid syntax
accepted by the java.net.URL constructor should work (such as
'jar:http://abcl-dynamic-install.googlecode.com/files/baz.jar!/a/b/eek.lisp').

The internal structure of a jar pathname has changed. Previously a
pathname with a DEVICE that was itself a pathname referenced a jar.
This convention was not able to simultaneously represent bothjar
entries that were themselves jar files as occurs with packed FASLs
within JARs and devices which refer to drive letters under Windows.
Now, a pathname which refers to a jar has a DEVICE which is a proper
list of at most two entries. The first entry always references the
"outer jar", and the second entry (if it exists) references the "inner
jar". Casual users are encouraged not to manipulate the "internal
structure" of jar pathname by setting its DEVICE directly, but instead
rely on namestring <--> pathname conversions.

Jar pathnames are only currently valid for use with LOAD, TRUENAME,
PROBE-FILE and pathname translation related functions (such as
MERGE-PATHNAMES, TRANSLATE-PATHNAME, etc.) Passing one to OPEN
currently signals an error. Jar pathnames do not currently work
with DIRECTORY or PROBE-DIRECTORY.

Jar pathnames work for ASDF systems packaged within JARs. We override
ASDF:LOAD-OP to load ASDF from JAR Pathnames by bypassing compilation
if the output location would be in a JAR file. Interaction with
ASDF-BINARY-LOCATIONS is currently untested.

Pathname now used as the basis of ABCL's internal routines for loading
FASLs replacing the use of strings, which simplifies a lot of the
behavior in looking for things to LOAD.

Fixed nasty shared structure bug on MERGE-PATHNAMES by implementing
(and using) a copy constructor for Pathname.

Implemented SYS:PATHNAME-JAR-P predicate for jar pathnames.

Removed ZipCache? as it is no longer used now that we are using JVM's
implicit JAR caching.

WRITE-FILE-DATE works for jar pathnames, returning 0 for a
non-existent entry.

JAR-FILE tests now include loading FASLs from network location, which
means that these tests will fail if there is no network
connectivity. The tests initialization rewritten in Lisp, so it works
under Windows.

Allow of a top directory for creating hierarchially ZIPs with SYS:ZIP.
There is now a three argument version--PATHNAME PATHNAMES &OPTIONAL
TOPDIR--whereby all pathnames will be interpolated relative to topdir.

Implementation of SYS:UNZIP to unpack ZIP/JAR files.

JAR files always use '/' to name hierarchial entries. Pathname
translates '/' --> '\' under isPlatformWindows for all hierarchy
*except* reference to jar entries.

Pathname URL constructor under Windows to properly parses the
drive letter.

Ensure that *EXT:LISP-HOME* contains a directory.

Removed unused imports.

Converted Primitives to stack-trace friendly form where we touched the
source extensively anyways.

File size: 5.6 KB
Line 
1JARs and JAR entries in ABCL
2============================
3
4Mark Evenson
5Created: 09 JAN 2010
6Modified: 24 JAN 2010
7
8Notes towards sketching an implementation of "jar:" references to be
9contained in PATHNAMEs within ABCL
10
11
12Goals
13-----
14
151.  Use Common Lisp pathnames to refer to entries in a JAR file.
16
17   
182.  Use 'jar:' schema as documented in java.net.JarURLConnection for
19    namestring representation.
20
21An entry in a JAR file:
22    #p"jar:file:baz.jar!/foo"
23   
24A JAR file:
25    #p"jar:file:baz.jar!/"
26
27A JAR file accessible via URL
28    #p"jar:http://example.org/abcl.jar!/"
29
30An entry in a ABCL FASL in a URL accessible JAR file
31    #p"jar:jar:http://example.org/abcl.jar!/foo.abcl!/foo-1.cls"
32
333.  MERGE-PATHNAMES working for JAR entries
34
35    (merge-pathnames "foo-1.cls" "jar:jar:file:baz.jar!/foo.abcl!/foo._")
36    "jar:jar:file:baz.jar!/foo.abcl!/foo-1.cls"
37
38    (merge-pathnames "foo-1.cls" "jar:file:foo.abcl!/")
39    "jar:file:foo.abcl!/foo-1.cls"
40
414.  TRUENAME and PROBE-FILE working with "jar:"
42
434.1  TRUENAME cannonicalizing the JAR reference.
44
455.  DIRECTORY working within JAR files (and within JAR in JAR).
46
476.  References "jar:<URL>" for all strings <URL> that java.net.URL can
48    resolve works.
49
50
51Implementation
52--------------
53
54Using PATHNAMES
55
56*   A PATHNAME refering to a file within a JAR is known as a JAR
57    PATHNAME.  It can either refer to the entire JAR file or an entry
58    within the JAR file.
59
60*   A JAR PATHNAME always has a DEVICE which is a proper list.  This
61    distinguishes it from other uses of Pathname. 
62
63*   The DEVICE of a JAR PATHNAME will be a list with either one or two
64    elements.  The first element of the JAR PATHNAME can be either a
65    PATHNAME representing a JAR on the filesystem, or a SimpleString
66    representing a URL.
67
68*   a PATHNAME occuring in the list in the DEVICE of a JAR PATHNAME is
69    known as a DEVICE PATHNAME.
70
71*   If the DEVICE is a String it must be a String that successfully
72    constructs a URL via the java.net.URL(String) constructor
73
74*   Only the first entry in the the DEVICE list may be a String.
75
76*   Otherwise the the DEVICE PATHAME denotes the PATHNAME of the JAR file
77
78*   The DEVICE PATHNAME list of enclosing JARs runs from outermost to
79    innermost.
80   
81
82
83Use Cases
84---------
85
86// UC1 -- JAR
87pathname: {
88  namestring: "jar:file:foo/baz.jar!/"
89  device: (
90    pathname: { 
91      device: "jar:file:"
92      directory: (:RELATIVE "foo")
93      name: "baz"
94      type: "jar"
95    }
96  )
97}
98
99
100// UC1 -- JAR entry
101pathname: {
102  namestring: "jar:file:baz.jar!/foo.abcl"
103  device: ( pathname: {
104    device: "jar:file:"
105    name: "baz"
106    type: "jar"
107  })
108  name: "foo"
109  type: "abcl"
110}
111
112
113// UC3 -- JAR file in a JAR entry
114pathname: {
115  namestring: "jar:jar:file:baz.jar!/foo.abcl!/"
116  device: (
117    pathname: {
118      name: "baz"
119      type: "jar"
120    }
121    pathname: {
122      name: "foo"
123      type: "abcl"
124    }
125  )
126}
127
128// UC4 -- JAR entry in a JAR entry with directories
129pathname: {
130  namestring: "jar:jar:file:a/baz.jar!/b/c/foo.abcl!/this/that/foo-20.cls"
131  device: (
132    pathname {
133      directory: (:RELATIVE "a")     
134      name: "bar"
135      type: "jar"
136    }
137    pathname {
138      directory: (:RELATIVE "b")
139      name: "foo"
140      type: "abcl"
141    }
142  )
143  directory: (:RELATIVE "this" "that")
144  name: "foo-20"
145  type: "cls"
146}
147
148// UC5 -- JAR Entry in a JAR Entry
149pathname: {
150  namestring: "jar:jar:file:a/foo/baz.jar!/foo.abcl!/a/b/bar-1.cls"
151  device: (
152    pathname: {
153      device: "jar:file:"
154      name: "baz"
155      type: "jar"
156    }
157    pathname: {
158      name: "foo"
159      type: "abcl"
160    }
161  )
162  name: "bar-1"
163  type: "cls"
164}
165
166// UC6 -- JAR entry in a http: accessible JAR file
167pathname: {
168  namestring: "jar:http://example.org/abcl.jar!/org/armedbear/lisp/Version.class",
169  device: (
170    "http://example.org/abcl.jar"
171    pathname: {
172      directory: (:relative "org" "armedbear" "lisp")
173      name: "Version"
174      type: "class"
175   }
176}
177
178// UC7 -- JAR Entry in a JAR Entry in a URL accessible JAR FILE
179pathname: {
180   namestring  "jar:jar:http://example.org/abcl.jar!/foo.abcl!/foo-1.cls"
181   device: (
182     "http://example.org/abcl.jar"
183     pathname: {
184       name: "foo"
185       type: "abcl"
186     }
187  )
188  name: "foo-1"
189  type: "cls"
190}
191
192// UC8 -- JAR in an absolute directory
193
194pathame: {
195   namestring: "jar:file:/a/b/foo.jar!/"
196   device: (
197     pathname: {
198       directory: (:ABSOLUTE "a" "b")
199       name: "foo"
200       type: "jar"
201     }
202   )
203}
204
205// UC9 -- JAR in an relative directory with entry
206pathname: {
207   namestring: "jar:file:a/b/foo.jar!/c/d/foo.lisp"
208   device: (
209     directory: (:RELATIVE "a" "b")
210     name: "foo"
211     type: "jar"
212   )
213   directory: (:RELATIVE "c" "d")
214   name: "foo"
215   type: "lisp
216}
217
218
219 
220Problems
221--------
222
2231.  DEVICE PATHNAMES require the context within the nested PATHNAME
224    structure to be interpreted correctly.
225
226Result:    Be careful when manipulating PATHNAMEs that refer to JARs
227
228
229History
230-------
231
232In the use of PATHNAMEs linked by the DEVICE field, we found the problem
233that UNC path support uses the DEVICE field
234
235Result:    JARs located on UNC mounts can't be referenced. via '\\'.
236
237           i.e.  jar:jar:file:\\server\share\a\b\foo.jar!/this\that!/foo.java
238
239would not have
240
241Solution:  Instead of having DEVICE point to a PATHNAME, have DEVICE
242be a list of PATHNAMES
243
244pathname: {
245  namestring: "jar:jar:file:\\server\share\foo.jar!/foo.abcl!/"
246  device: ( pathname: {
247              name: "foo"
248              type: "abcl"
249            }
250            pathname: {
251              host: "server"
252              device: "share"
253              name: "foo"
254              type: "jar"
255            }
256}
257
258Which order for the list? Outermost first or last?  Outermost first.
259
Note: See TracBrowser for help on using the repository browser.