[armedbear-devel] cffi requires maven
Hello. In ABCL CFFI requires maven. Maven is used to fetch jna.jar. This is done via abcl-contrib.jar/mvn/jna.asd What I think is inconvenient is that maven is tried even if jna.jar is in classpath. IMHO it would be to not require maven installed if JNA is available. The current workaround is (provide 'jna). With that I can do: (java:add-to-classpath "my-jna/jna.jar") (provide 'jna) (ql:quickload :drakma) BTW, I think it's probably makes sense to ship jna.jar together with official ABCL release. Best regards, - Anton
On 10/12/12 1:18 PM, Anton Vodonosov wrote:
Hello.
In ABCL CFFI requires maven.
Correct. Ideally we'd like to outsource the meaning of further binary artifacts away from the core 8Mib abcl.jar.
What I think is inconvenient is that maven is tried even if jna.jar is in classpath. IMHO it would be to not require maven installed if JNA is available.
Agreed. There's an example of introspecting the java CLASSPATH in the code for loading ABCL-CONTRIB which I just have to clone and adopt. Unless someone beats me too it… Please let me know if this doesn't work for you.
BTW, I think it's probably makes sense to ship jna.jar together with official ABCL release.
We will provide the ability to download these artifacts yourself with an interactive restart in abcl-1.1.0, as you have to ensure that your local licensing terms apply. Me? I'm a BSD guy living in penguin land… [r14187]: http://trac.common-lisp.net/armedbear/changeset/14187 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."
On 10/12/12 2:10 PM, Mark Evenson wrote:
On 10/12/12 1:18 PM, Anton Vodonosov wrote:
In ABCL CFFI requires maven.
Correct. Ideally we'd like to outsource the meaning of further binary artifacts away from the core 8Mib abcl.jar.
What I think is inconvenient is that maven is tried even if jna.jar is in classpath. IMHO it would be to not require maven installed if JNA is available.
Agreed. There's an example of introspecting the java CLASSPATH in the code for loading ABCL-CONTRIB which I just have to clone and adopt. Unless someone beats me too it…
[…] A speculative implementation of your proposal has been committed. I *think* I have [implemented your suggestion correctly on trunk][1]. Please let me know if *this* doesn't work. [1]: http://goo.gl/XZ24Q -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."
12.10.2012, 16:11, "Mark Evenson" <evenson@panix.com>:
Agreed. There's an example of introspecting the java CLASSPATH in the code for loading ABCL-CONTRIB which I just have to clone and adopt. Unless someone beats me too it…
Just an idea: an alternative to instropsection of CLASSPATH can be attempt to access some JNA class, e.g. com.sun.jna.Native, and in case of ClassNotFound exception deduce JNA is not available.
On 10/12/12 2:46 PM, Anton Vodonosov wrote:
Just an idea: an alternative to instropsection of CLASSPATH can be attempt to access some JNA class, e.g. com.sun.jna.Native, and in case of ClassNotFound exception deduce JNA is not available.
Good idea! [Implemented in trunk][r14189]. [r14189]: http://trac.common-lisp.net/armedbear/changeset/14189 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."
On 12 October 2012 15:53, Mark Evenson <evenson@panix.com> wrote:
On 10/12/12 2:46 PM, Anton Vodonosov wrote:
Just an idea: an alternative to instropsection of CLASSPATH can be attempt to access some JNA class, e.g. com.sun.jna.Native, and in case of ClassNotFound exception deduce JNA is not available. Good idea! [Implemented in trunk][r14189]. [r14189]: http://trac.common-lisp.net/armedbear/changeset/14189
Heh, as far as I understand, we have used a similar approach for detecting the presence of JSR-223, although we do that at build-time.
12.10.2012, 17:31, "Anton Vodonosov" <avodonosov@yandex.ru>:
Tested revesion 14189 - works for me, maven is not tried when JNA is in classpath.
Something has changed since revision 14189 - maven is now tried even if JNA is in classpath. I am not sure, but probably happens before asdf:load-op, at the time of defsystem including component (:mvn "net.java.dev.jna/jna/3.5.1").
On Nov 6, 2012, at 5:14 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
12.10.2012, 17:31, "Anton Vodonosov" <avodonosov@yandex.ru>:
Tested revesion 14189 - works for me, maven is not tried when JNA is in classpath.
Something has changed since revision 14189 - maven is now tried even if JNA is in classpath.
I am not sure, but probably happens before asdf:load-op, at the time of defsystem including component (:mvn "net.java.dev.jna/jna/3.5.1").
I substantially re-worked the logic in [r14236][], pushing the resolution logic entirely into my method, instead of trying to figure out the right dance with CLOS that ASDF performs to load things. The MVN component now takes a :CLASSNAME argument to specify the class that indicates that the binary artifact has been loaded. [r14236]: http://trac.common-lisp.net/armedbear/changeset/14236 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
participants (3)
-
Anton Vodonosov -
Mark Evenson -
Ville Voutilainen