[asdf-devel] ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)

[Faré]

> I'm gonna need a bit more time to chew over the ASDF code, but thanks for
> the general direction.  I must confess that in spite of the reasonable
> looking documentation and having contributed the function translation code
> to ASDF, its whole output translation API has never really gelled in my
> understanding as a totality.  Maybe I can contribute some examples to the
> texinfo file when the fuzz in my understanding resolves a bit.
>
output-translations is not THAT hard to understand,
if you read the source code with my previous comments in mind.
Patches to the docs are welcome, too.

> A reasonable packaging mechanism for ABCL plus "compiled stuff" composed of
> ASDF system definitions that works well in a Java ecosystem is precisely the
> itch I'm in the process of scratching for ABCL right now.
Excellent. I hope you provide an API that isn't so ASDF-specific that it's
a pain to use with XCVB -- though XCVB can use ASDF as a backend, and
considering the slow ABCL start time, it's probably to be the preferred
backend on ABCL.

> 1)  You can't immediately load FASL out of the jar.
Is that an ABCL limitation?

> In my current hackish
> way—i.e. without comprehending your advice yet—one has first ASDF compile
> the system with output translations disabled, and then
>
>  (defmethod asdf:perform ((o asdf:compile-op) (c asdf:cl-source-file)))
>  (setf (asdf::output-translations) '((t t))))
>
> in the target JVM to load the ABCL FASLS from the jar.
>
Why that pain? Doesn't the zip process preserve the timestamps?

> 2) One has to specify the absolute path on the local filesystem (or
> potentially via a URI) for the jar, which makes things a bit fragile in the
> typical Java ecosystem usage which shuffles jars around like win32 DLLs (or,
> to be fair, Unix dynamic libraries) relying merely on the filename to keep
> things straight.  My current insight into a way around would be to define
> another PATHNAME extension in ABCL for CLASSPATH entries, i.e.
> "classpath:cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" would refer to the named jar
> in the JVM CLASSPATH if it exists.
>
You want CL systems to be in a variety of jars,
rather than just a one jar with everything in it?

> 4)  The extremely nice use of [JSS][jss] and [ABCLD's slight
> modification][abcld] of ASDF to also refer to jar files to dynamically load
> into the JVM probably needs to be rewritten, otherwise we run into the
> situation whereby we have jars (i.e. the packaged Java code) within the ASDF
> packaged jar which A) needs changes within ABCL to completely work and B)
> would be rather inefficient in that the naive implementation  each request
> for a new entry in the JAR within a JAR would require a complete "reseek"
> through the enclosed ZIP file.
>
> [jss]: http://code.google.com/p/lsw2/source/browse/#svn%2Ftrunk%2Fjss
> [abcld]:
> http://code.google.com/p/abcl-dynamic-install/source/browse?repo=abcld
>
I welcome patches to ASDF and/or implementation-specific contributions,
just like our asdf-ecl.lisp.

> 5)  A fear of mine: if I enable all this, I presume that people would start
> going around creating 'abcl.jar' files with different inclusions of
> different ASDF packagings.  Without a real smart dynamic introspection
> system that essentially solves the problems in JVM's classpath we would end
> up with, at the minimum, a rather hostile situation for the end user.  "Put
> 'abcl.jar' in your classpath."  "I did, and it still didn't load Maxima."
>  "Well, what's the checksum of your abcl.jar?" "c48d359a23ee"  "Oh, you need
> 846f78c279cb".  Ideally, I would like to come up with a mechanism that would
> require that 'abcl.jar' come from "official" ABCL packaging, but would
> somehow be able to introspect the JVM classpath to include ASDF definitions.
>
Maybe make it hard for anything but the original to be named abcl.jar?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Backwards compatible — If it's not backwards it's not compatible
	— Greg Newton <gregnewton at netscape.net>