<html><body bgcolor="#FFFFFF"><div><br></div><div>On May 20, 2011, at 5:26 PM, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><span>On Fri, May 20, 2011 at 4:38 PM, Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:</span><br><font class="Apple-style-span" color="#005001">[.…]<br></font><blockquote type="cite"><span>I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most</span><br></blockquote><blockquote type="cite"><span>of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL</span><br></blockquote><blockquote type="cite"><span>Java routines have evolved to a point that none of the external JAR</span><br></blockquote><blockquote type="cite"><span>dependencies should be necessary. When jscheme.jar is eliminated, we will</span><br></blockquote><blockquote type="cite"><span>be able to load JSS quite comfortably from abcl-contrib.jar (even over the</span><br></blockquote><blockquote type="cite"><span>network).</span><br></blockquote><span></span><br><span>What is jscheme.jar still needed for?</span><br><span></span><br></div></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"><div><blockquote type="cite"><span>With the additional syntax for ASDF, we will be able to start</span><br></blockquote><blockquote type="cite"><span>formalizing a packaging mechanism that allows us to mix Lisp/Java libraries</span><br></blockquote><blockquote type="cite"><span>in a systematic manner.</span><br></blockquote><span></span><br><span>+1 for that! I'd love to have something like Leiningen for Clojure</span><br><span>integrated with ASDF, leveraging Maven for dependency resolution (and</span><br><span>only for that). e.g. (:depends-on (maven-dep "com.foo" "bar"</span><br><span>"1.2.3")).</span><br></div></blockquote><div><br></div>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.<div><br></div><div>Would Leiningen be something we should study/adapt in this direction?</div><div><div><br><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><div><br><br>Sent from my iPad</div><div><br></div></span></div></div></body></html>