Skip to content
  • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
    Extensively reworked new implementation for specifiying jar pathnames. · fe838110
    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.
    fe838110