[armedbear-devel] Tentative inclusion of JSS with ABCL contrib

[Alessio Stalla]

On Fri, May 20, 2011 at 6:28 PM, Mark Evenson <evenson at panix.com> wrote:
>
> On May 20, 2011, at 5:26 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
>
> On Fri, May 20, 2011 at 4:38 PM, Mark Evenson <evenson at panix.com> wrote:
> [.…]
>
> I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most
>
> of INVOKE-RESTARGS without the jscheme.jar stuff.   Essentially the ABCL
>
> Java routines have evolved to a point that none of the external JAR
>
> dependencies should be necessary.  When jscheme.jar is eliminated, we will
>
> be able to load JSS quite comfortably from abcl-contrib.jar (even over the
>
> network).
>
> What is jscheme.jar still needed for?
>
>
> Not much: I seemed to have successfully ported INVOKE-RESTARGS in my first
> commit.  I think will the subsequent elimination of the #1"something" macro
> that I was reluctant to do without confirmation from Alan will finish the
> job.  But I have to check a little more thoroughly.  It turns out that when
> you worked on the JCALL methods in imitation ok JSS, you did most (all?) the
> necessary work on the ABCL side.
>
> With the additional syntax for ASDF, we will be able to start
>
> formalizing a packaging mechanism that allows us to mix Lisp/Java libraries
>
> in a systematic manner.
>
> +1 for that! I'd love to have something like Leiningen for Clojure
> integrated with ASDF, leveraging Maven for dependency resolution (and
> only for that). e.g. (:depends-on (maven-dep "com.foo" "bar"
> "1.2.3")).
>
> I'd definitely like your ideas on this once I get JSS comfortably loading
> from its ASDF form packaged in a jar.  I intend to create a utility that
> given ASDF definitions as input, will output systems packaged in a jar or
> jars.  One problem in my current thinking is what to do about the jar-file
> type in ASDF definitions once they are packaged in a jar.  Should we
> implicitly (or explicitly) rewrite the definition from a filesystem relative
> location for the jar to something that says "look this up in the classpath"?
> Or should we include the "Java" jars inside the ASDF jar? The former leads
> to less than seemless deploment. The later seems grossly inefficient.  In
> some ways, I fear that this sort of dependency packaging is beyond what ASDF
> can comfortably handle, and that we would need to invent a DSL to describe
> dependencies on Java libraries, ideally that can export/import from Ivy,
> Maven, and OSGi descriptions.
> Would Leiningen be something we should study/adapt in this direction?

I don't know Leiningen well enough to know; I don't use Clojure, I
just lurk on their mailing list a bit. I think though that we should
keep dependencies and packaging separated, just like they're now in
ASDF for Lisp. ASDF simply fetches dependencies from known places,
compiles and loads the code. How you package your software and where
you put your dependencies isn't ASDF's business; it just needs to find
the dependencies when it needs them.
This means that if we go the Maven route it's Maven who downloads and
stores libraries in its local repository; ASDF merely adds them to the
classpath while compiling/loading. Just like Quicklisp does: it
downloads dependencies, puts them somewhere, and tells ASDF where to
find them. Except that Quicklisp --uses--> ASDF while I'd like that
ASDF --used--> Maven.

Alessio