ASDF configuration for "JAR-only" system

John Pallister john at
Mon Dec 14 23:03:41 UTC 2015

Hello again,

As often happens, describing the problem in detail prompted my brain to
come up with another idea. I changed my output translation configuration to:

    (,(let* ((device (pathname-device *application-jar-path*))
    (path (merge-pathnames "**/*.*" *application-jar-path*)))
  (make-pathname :defaults path :device device)))

And now I don't get the "access denied" error, but it seems that

On 14 December 2015 at 22:39, John Pallister <john at> wrote:

> Hello list,
> I'm trying to configure ASDF to load my application while running within
> the Google App Engine development server (Jetty 6.1). My Ant build script
> uses ASDF-JAR:PACKAGE to produce a single JAR file containing my
> application and all dependencies, and copies this to the war/WEB-INF/lib/
> directory so that it's in the classpath.
> At runtime (in a separate bootstrap.lisp file), following the example of
> ASDF-JAR:ADD-TO-ASDF[1], I search the application JAR file (obtained by
> grovelling JAVA:DUMP-CLASSPATH) for the .ASD files and push them all onto
> ASDF:*CENTRAL-REGISTRY*. So far so good. (Having read the ASDF manual I now
> know I should either build a .cl-source-registry.cache file into the JAR or
> compute an ASDF source registry configuration and include that.)
> When ASDF starts up it tries to read various configuration files from the
> filesystem, for both the source registry and for its output translations.
> This isn't allowed by App Engine. On #lisp, Attila Lendvai suggested that
> giving ASDF a source registry configuration of '(:SOURCE-REGISTRY
> :IGNORE-INHERITED-CONFIGURATION) should suppress this behaviour, and it
> does seem to work.
> Now I'm struggling to get the output translations to work. Based on
> ADD-TO-ASDF again I'm using an output translations configuration of:
> `(:output-translations
>     (,(merge-pathnames "/**/*.*" *application-jar-path*)) ; => #P"/**/*.*"
>     :ignore-inherited-configuration
>     :disable-cache)
> #P"jar:file:/Volumes/SoftRAID/Users/john/src/synchromesh/forumfeedme/war/WEB-INF/lib/forumfeedme-lisp-0.1.0.jar!/",
> i.e. a pathname with the JAR path as the PATHNAME-DEVICE.
> With this I get the error "access denied (""
> "/___jar___file___root___" "read")". This matches the default translations
>   (defun wrapping-output-translations ()
>     `(:output-translations
>     ;; Some implementations have precompiled ASDF systems,
>     ;; so we must disable translations for implementation paths.
>       #+(or #|clozure|# ecl mkcl sbcl)
>       ,@(let ((h (resolve-symlinks* (lisp-implementation-directory))))
>           (when h `(((,h ,*wild-path*) ()))))
>       #+mkcl (,(translate-logical-pathname "CONTRIB:") ())
>       ;; All-import, here is where we want user stuff to be:
>       :inherit-configuration
>       ;; These are for convenience, and can be overridden by the user:
>       #+abcl (#p"/___jar___file___root___/**/*.*" (:user-cache #p"**/*.*"))
>       #+abcl (#p"jar:file:/**/*.jar!/**/*.*" (:function
> translate-jar-pathname))
>       ;; We enable the user cache by default, and here is the place we do:
>       :enable-user-cache))
> Although I don't understand exactly how the "JAR file as device" (JFAD)
> translations are supposed to work, one thing that struck me as odd while
> investigating things was this:
> CL-USER> (make-pathname :device (list #P"/foo.jar"))
> #P"jar:file:/foo.jar!/"
> CL-USER> (merge-pathnames "**/*.*" *)
> #P"jar:file:/foo.jar!/**/*.*"
> CL-USER> (merge-pathnames "/**/*.*" **)
> #P"/**/*.*"
> CL-USER> (pathname-directory **)
> CL-USER> (pathname-directory **)
> That is, merging a relative path with the (absolute) JFAD path retained
> the default JAR file "device" (and remains a relative path, which ASDF
> won't accept), but merging an absolute path reset the device component.
> I've read through the documentation for MERGE-PATHNAMES in the HyperSpec[2]
> and AFAICT the device component should be copied across. I'm reasonably
> confident that if it were, things would work better. But I could be
> (doubly) wrong.
> I am trying to figure this out for myself, but I'm stuck for now, so I'm
> hoping someone (i.e. Mark) can, on reading this, offer some guidance as to
> where I should go from here. I haven't (yet) tried posting to the ASDF
> mailing list as this seems like a fairly ABCL-specific issue.
> I guess the fallback is to unpack the application JAR and just load the
> FASLs directly, but (based again on ADD-TO-ASDF) I'm pretty sure that this
> should work, and it does seem to be the Right Thing.
> Any or all comments and/or advice appreciated,
> Cheers,
> John :^P
> [1]
> [2]
> --
> John Pallister
> john at
> john at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the armedbear-devel mailing list