[armedbear-devel] installing java dependencies with :mvn ASDF component
Hello. I need to import data from Excel, and following Hans Hübner's article for how to do this with ABCL: http://netzhansa.blogspot.com/2013/03/dealing-with-excel-files-from-common.h... The Hans' code depends on Apache POI library. I saw that ABCL comes from abcl-asdf contrib, which extends ASDF by adding a :mnv component, so that we can specify :mvn artifact as a dependency of our ASDF system. I would like to use this facility to automatically install the POI .jar files. I created an .asdf file with this content: (defsystem :excel-s :defsystem-depends-on (:abcl-asdf) :version "0.1.0" :encoding :utf-8 :components ((:mvn "org.apache.poi/poi-ooxml/3.9"))) Then I invoke ABCL: C:\Users\anton\projects\abcl\abcl.bat --batch --eval "(require :abcl-contrib") --eval "(pushnew \"./\" asdf:*central-registry* :test #'equal)" --eval "(ql:quickload :excel-s)" It fails with exception: java.lang.ClassNotFoundException: aether.util.artifact.DefaultArtifact This exception is throw by abcl-asdf::resolve-dependencies function, defined in the contrib/abcl-asdf/maven-embedder.lisp. Maven is installed on my machine, including the /lib/ directory containing the Aether API jars. I performed some investigation and tried to ensure the Aether .jars are added to classpath: (abcl-asdf::init) (let ((*default-pathname-defaults* abcl-asdf::*mvn-libs-directory*)) (dolist (jar-pathname (or (directory "**/*.jar") (error "no jars found in ~S - expected Apache Maven /libs/ directory ~ installation there" (merge-pathnames abcl-asdf::*mvn-libs-directory*)))) (java:add-to-classpath (namestring jar-pathname)))) Still I have the same error - class aether.util.artifact.DefaultArtifact not found. Is the way I am trying to install java libs expected to work, and how to find the problem? Best regards, - Anton
I think I found the reason. I am using the latest maven 3.1.0. The Aether API has moved to another packages: org.eclipse.aether.* I have changed contrib/abcl-asdf/maven-embedder.lisp file to use new java class names (as in the addached svn.diff), and the error seems gone. I continue to work on the Excel improt, will here report if find new information. Best regards, - Anton 10.08.2013, 01:01, "Anton Vodonosov" <avodonosov@yandex.ru>:
Hello.
I need to import data from Excel, and following Hans Hübner's article for how to do this with ABCL: http://netzhansa.blogspot.com/2013/03/dealing-with-excel-files-from-common.h...
The Hans' code depends on Apache POI library.
I saw that ABCL comes from abcl-asdf contrib, which extends ASDF by adding a :mnv component, so that we can specify :mvn artifact as a dependency of our ASDF system. I would like to use this facility to automatically install the POI .jar files.
I created an .asdf file with this content:
(defsystem :excel-s :defsystem-depends-on (:abcl-asdf) :version "0.1.0" :encoding :utf-8 :components ((:mvn "org.apache.poi/poi-ooxml/3.9")))
Then I invoke ABCL: C:\Users\anton\projects\abcl\abcl.bat --batch --eval "(require :abcl-contrib") --eval "(pushnew \"./\" asdf:*central-registry* :test #'equal)" --eval "(ql:quickload :excel-s)"
It fails with exception: java.lang.ClassNotFoundException: aether.util.artifact.DefaultArtifact This exception is throw by abcl-asdf::resolve-dependencies function, defined in the contrib/abcl-asdf/maven-embedder.lisp.
Maven is installed on my machine, including the /lib/ directory containing the Aether API jars.
I performed some investigation and tried to ensure the Aether .jars are added to classpath:
(abcl-asdf::init) (let ((*default-pathname-defaults* abcl-asdf::*mvn-libs-directory*)) (dolist (jar-pathname (or (directory "**/*.jar") (error "no jars found in ~S - expected Apache Maven /libs/ directory ~ installation there" (merge-pathnames abcl-asdf::*mvn-libs-directory*)))) (java:add-to-classpath (namestring jar-pathname))))
Still I have the same error - class aether.util.artifact.DefaultArtifact not found.
Is the way I am trying to install java libs expected to work, and how to find the problem?
Best regards, - Anton
The diff from the previous message had several problems. After fixing the problems one by one I now have working version - see svn.diff attached (can't submit it as a ticket, because don't know how to login into the new ABCL Trac). I must say I now feel how convenient :mvn ASDEF componets are. I just do (ql:quickload :my-system) and it automatically installs and loads all the Lisp and Java dependencies (ApachePOI takes 8 .jar files to install). As for keeping compatibility with old maven. Various approaches possible here. I would suggest to commit my patch and be compatible with the latest maven version. If necessary, record a separate ticket to generalize/conditionalize the :mvn components implementation to make it compatible with both old and new maven. Best regards, - Anton P.S. Maven 3.1.0 release notes, where they describe Aether API change: http://maven.apache.org/docs/3.1.0/release-notes.html 10.08.2013, 01:40, "Anton Vodonosov" <avodonosov@yandex.ru>:
I think I found the reason.
I am using the latest maven 3.1.0. The Aether API has moved to another packages: org.eclipse.aether.*
I have changed contrib/abcl-asdf/maven-embedder.lisp file to use new java class names (as in the addached svn.diff), and the error seems gone.
I continue to work on the Excel improt, will here report if find new information.
Best regards, - Anton
10.08.2013, 01:01, "Anton Vodonosov" <avodonosov@yandex.ru>:
Hello.
I need to import data from Excel, and following Hans Hübner's article for how to do this with ABCL: http://netzhansa.blogspot.com/2013/03/dealing-with-excel-files-from-common.h...
The Hans' code depends on Apache POI library.
I saw that ABCL comes from abcl-asdf contrib, which extends ASDF by adding a :mnv component, so that we can specify :mvn artifact as a dependency of our ASDF system. I would like to use this facility to automatically install the POI .jar files.
I created an .asdf file with this content:
(defsystem :excel-s :defsystem-depends-on (:abcl-asdf) :version "0.1.0" :encoding :utf-8 :components ((:mvn "org.apache.poi/poi-ooxml/3.9")))
Then I invoke ABCL: C:\Users\anton\projects\abcl\abcl.bat --batch --eval "(require :abcl-contrib") --eval "(pushnew \"./\" asdf:*central-registry* :test #'equal)" --eval "(ql:quickload :excel-s)"
It fails with exception: java.lang.ClassNotFoundException: aether.util.artifact.DefaultArtifact This exception is throw by abcl-asdf::resolve-dependencies function, defined in the contrib/abcl-asdf/maven-embedder.lisp.
Maven is installed on my machine, including the /lib/ directory containing the Aether API jars.
I performed some investigation and tried to ensure the Aether .jars are added to classpath:
(abcl-asdf::init) (let ((*default-pathname-defaults* abcl-asdf::*mvn-libs-directory*)) (dolist (jar-pathname (or (directory "**/*.jar") (error "no jars found in ~S - expected Apache Maven /libs/ directory ~ installation there" (merge-pathnames abcl-asdf::*mvn-libs-directory*)))) (java:add-to-classpath (namestring jar-pathname))))
Still I have the same error - class aether.util.artifact.DefaultArtifact not found.
Is the way I am trying to install java libs expected to work, and how to find the problem?
Best regards, - Anton
On 8/10/13 5:03 AM, Anton Vodonosov wrote:
The diff from the previous message had several problems.
Thanks so much for the patch: I remember that the last time I tracked the problems resulting from a Aether version change as being really not a fun experience.
After fixing the problems one by one I now have working version - see svn.diff attached (can't submit it as a ticket, because don't know how to login into the new ABCL Trac).
One should be able to login to the [ABCL Trac][1] with any [OpenID][openid] or a common-lisp.net http digest password valid in April 2013. I'd be happy to help you "track" down why this isn't working for you… [1]: http://lisp.not.org/trac/armedbear [openid]: https://en.wikipedia.org/wiki/Openid
I must say I now feel how convenient :mvn ASDEF componets are. I just do (ql:quickload :my-system) and it automatically installs and loads all the Lisp and Java dependencies (ApachePOI takes 8 .jar files to install).
I've always thought :MVN ASDF components as an especially useful feature as well for Java interop. Even though using Maven from straight "Java the language" development has its pain points, the distributed POM graph is quite useful. Now that Aether has apparently moved to being an Apache project, using it should be more stable (after this initial pain point).
As for keeping compatibility with old maven. Various approaches possible here. I would suggest to commit my patch and be compatible with the latest maven version. If necessary, record a separate ticket to generalize/conditionalize the :mvn components implementation to make it compatible with both old and new maven.
Unfortunately, I disagree with dropping support for pre maven-3.1.0 by committing your patch as this would be disruptive to those following trunk who haven't updated their Maven installations yet. Of course, our survey size for determining this course of inaction was rather small. Well, ok, the survey only included me, but since maven-3.1.0 has not shown up upstream in any of the OS package systems that I actively use (FreeBSD, MacPorts, Debian, OpenIndiana), I am pretty sure that I am not the only one that would be disrupted (if there are more users of ABCL-ASDF than you and I, of course…) That being said, I will endeavor to incorporate your patch in a way which maintains compatibility into trunk in the next few days. Other than a hack 'n slash (IF old-maven new-maven) job, I wonder if there is a more elegant way to deal with the package change. My gut feeling is that I would need to re-organize the code so substantially, that I would then have to chase down bugs from that reorg. If it were just a simple renaming of package, I think I could whip up an appropiate macro, but from looking at your patch, it seems that there are a couple behavioral API changes as well. Anyone have any elegant ideas on how to maintain compatibility with both versions of Aether or point to an example of something clever that I can study for inspiration? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
10.08.2013, 12:25, "Mark Evenson" <evenson@panix.com>:
That being said, I will endeavor to incorporate your patch in a way which maintains compatibility into trunk in the next few days.
Other than a hack 'n slash (IF old-maven new-maven) job, I wonder if there is a more elegant way to deal with the package change. My gut feeling is that I would need to re-organize the code so substantially, that I would then have to chase down bugs from that reorg. If it were just a simple renaming of package, I think I could whip up an appropiate macro, but from looking at your patch, it seems that there are a couple behavioral API changes as well.
Anyone have any elegant ideas on how to maintain compatibility with both versions of Aether or point to an example of something clever that I can study for inspiration?
What if we then keep contrib/abcl-asdf/maven-embedder.lisp (mostly) unchanged, and just put new code into maven-3.1-embedder.lisp, giving it a separate package. Then we have (defmethod abcl-asdf::resolve ((string string)) (if (version> (mvn-version) "3.1") (maven-3.1-embedder:resolve string) (maven-embedder:resolve string)) So, the only thing to factor-out is maven version testing. After doing so, we can keep old versoin of maven-embedder immutable forever, thug avoiding testing and bugs in it. If someday (some years later) we decide the old maven support is not relevant anymore, we can just delete the maven-embedder.lisp
On Aug 10, 2013, at 1106 , Anton Vodonosov <avodonosov@yandex.ru> wrote: […]
What if we then keep contrib/abcl-asdf/maven-embedder.lisp (mostly) unchanged, and just put new code into maven-3.1-embedder.lisp, giving it a separate package.
Then we have
(defmethod abcl-asdf::resolve ((string string)) (if (version> (mvn-version) "3.1") (maven-3.1-embedder:resolve string) (maven-embedder:resolve string))
So, the only thing to factor-out is maven version testing.
Unfortunately, I think that the abstraction is not solely contained in ABCL-ASDF:RESOLVE, but also ABCL-ASDF:RESOLVE-DEPENDENCIES. RESOLVE should be sole entry point, but there are a number of ways I wish to call it (with #\: separated ids, with #\\ separated ids, with a variable number of strings) that I never have finished working over. Since getting to this in the "next few days" has proved to optimistic, I have filed a [ticket][328] so people can find the patch as well if they absolute need it in the meantime. [#328]: http://lisp.not.org/trac/armedbear/ticket/328 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
10.08.2013, 12:25, "Mark Evenson" <evenson@panix.com>:
One should be able to login to the [ABCL Trac][1] with any [OpenID][openid] or a common-lisp.net http digest password valid in April 2013. I'd be happy to help you "track" down why this isn't working for you…
[1]: http://lisp.not.org/trac/armedbear [openid]: https://en.wikipedia.org/wiki/Openid
Now that I remember my common-lisp.net digest password for Trac I can login into new armedbear trac. It was OpenID that I tried first. with Google as an indentity provider. It fails. Seems like your server cant fetch HTTP URL (the OpenID identifier) when performing discovery. Other OpenID clients (like this one http://cl-openid-demo.herokuapp.com/) can login me with Google, so the problem is not on the Google side.
On 8/10/13 5:03 AM, Anton Vodonosov wrote: […]
After fixing the problems one by one I now have working version - see svn.diff attached (can't submit it as a ticket, because don't know how to login into the new ABCL Trac).
I must say I now feel how convenient :mvn ASDEF componets are. I just do (ql:quickload :my-system) and it automatically installs and loads all the Lisp and Java dependencies (ApachePOI takes 8 .jar files to install).
As for keeping compatibility with old maven. Various approaches possible here. I would suggest to commit my patch and be compatible with the latest maven version. If necessary, record a separate ticket to generalize/conditionalize the :mvn components implementation to make it compatible with both old and new maven. […]
I've used your patch as the basis for a version compatible with all versions of Maven from 3.0.3 onwards in [r14574][]. [r14574]: http://lisp.not.org/trac/armedbear/changeset/14574 Hopefully this now works for everyone: lemme know if that is not the case. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Thanks a lot! 16.08.2013, 15:47, "Mark Evenson" <evenson@panix.com>:
On 8/10/13 5:03 AM, Anton Vodonosov wrote: […]
After fixing the problems one by one I now have working version - see svn.diff attached (can't submit it as a ticket, because don't know how to login into the new ABCL Trac).
I must say I now feel how convenient :mvn ASDEF componets are. I just do (ql:quickload :my-system) and it automatically installs and loads all the Lisp and Java dependencies (ApachePOI takes 8 .jar files to install).
As for keeping compatibility with old maven. Various approaches possible here. I would suggest to commit my patch and be compatible with the latest maven version. If necessary, record a separate ticket to generalize/conditionalize the :mvn components implementation to make it compatible with both old and new maven.
[…]
I've used your patch as the basis for a version compatible with all versions of Maven from 3.0.3 onwards in [r14574][].
[r14574]: http://lisp.not.org/trac/armedbear/changeset/14574
Hopefully this now works for everyone: lemme know if that is not the case.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (2)
-
Anton Vodonosov -
Mark Evenson