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?



Sent from my iPad