Maven and ABCL

Alan Ruttenberg alanruttenberg at
Fri Apr 7 20:27:25 UTC 2017

Here's a (perhaps hacky) fix for the moment.

Lets me write:

(asdf:defsystem owl2libs-mvn2
  :description "Non-Lisp dependencies necessary for OWL to function."
  ((:mvn-module "maven"
   (:module rest :pathname "lib" :components
            ((:jar-file "factplusplus-1.6.4-SNAPSHOT")
    (:jar-file "LSWTreeview-1.0.0")
    (:jar-file "QuotedStringAnnotationVisitor-1.0.0")))
   (:module lib :pathname "lib"
    :depends-on ("maven" rest))))

It doesn't address what to do about potentially conflicting maven artifacts
loaded by distinct asdf systems.

On Fri, Apr 7, 2017 at 11:50 AM, Alan Ruttenberg <alanruttenberg at>

> I'm using :mvn ASDF components and ran into a problem with having multiple
> versions of the same library. The issue boils down to the fact that ABCL
> currently processes dependencies for :mvn components one at a time, which
> doesn't take into account mutual dependencies. Attached is a
> function resolve-multiple-maven-dependencies, which takes a set of maven
> components and computes the dependencies. As an example, here is a
> comparison of treating the dependencies individually vs at once.
> (length (mapcan 'resolve-multiple-maven-dependencies
> '(("net.sourceforge.owlapi:owlapi-distribution:4.2.6")
>   ("net.sourceforge.owlapi:org.semanticweb.hermit:")
>   ("org.semanticweb.elk/elk-reasoner/0.4.3")
>   ("net.sourceforge.owlapi/pellet-cli-ignazio1977/2.4.0-ignazio1977")
>   ("net.sourceforge.owlapi/owlexplanation/2.0.0"))))
> -> 210
> (length (mapcan 'resolve-multiple-maven-dependencies
> '(("net.sourceforge.owlapi:owlapi-distribution:4.2.6"
>    "net.sourceforge.owlapi:org.semanticweb.hermit:"
>    "org.semanticweb.elk/elk-reasoner/0.4.3"
>    "net.sourceforge.owlapi/pellet-cli-ignazio1977/2.4.0-ignazio1977"
>    "net.sourceforge.owlapi/owlexplanation/2.0.0"))))
> -> 90
> In particular there are several versions of owlapi-distribution that are
> put on the classpath. Which one is actually used is not easily predictable.
> In my case even though I specified version 4.2.6 in my system definition,
> 4.1.3 was actually used.
> The attached code also has features not yet supported by the :mvn syntax
> that are really needed: The ability to override versions of a particular
> dependency that a downstream dependency specifies, and the ability to
> exclude certain artifacts altogether.
> Mark has suggested that the maven resolution could be moved to the ASDF
> planning stage, which sounds like a good idea. However there is still an
> issue regarding maven dependencies in different loaded ASDF systems. One
> idea is to remember dependencies  across systems and then uses them as
> constraints on subsequent maven resolutions.
> Comments and ideas would be appreciated.
> Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the armedbear-devel mailing list