On Fri, May 20, 2011 at 6:28 PM, Mark Evenson evenson@panix.com wrote:
On May 20, 2011, at 5:26 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Fri, May 20, 2011 at 4:38 PM, Mark Evenson evenson@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