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

https://github.com/alanruttenberg/abcl/commit/fab11a1b35ff143ed28d4c2f08f4fcff0d304c62

Lets me write:

(asdf:defsystem owl2libs-mvn2

:description "Non-Lisp dependencies necessary for OWL to function."

:components

((:mvn-module "maven"

:dependencies

("net.sourceforge.owlapi/pellet-cli-ignazio1977/2.4.0-ignazio1977"

"org.semanticweb.elk/elk-reasoner/0.4.3"

"net.sourceforge.owlapi/org.semanticweb.hermit/1.3.8.413"

"net.sourceforge.owlapi/owlapi-distribution/4.2.6"

"net.sourceforge.owlapi/owlexplanation/2.0.0"

"de.sciss/prefuse-core/1.0.1"

"de.sciss/prefuse-demos/1.0.1")

:managed-dependencies

("org.slf4j/slf4j-api/1.7.21"

"net.sourceforge.owlapi:owlapi-distribution:4.2.6")

:exclusions

("net.sourceforge.owlapi:owlapi-osgidistribution"

"edu.stanford.protege:org.protege.editor.owl"))

(: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@gmail.com> wrote:

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:1.3.8.413")
("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:1.3.8.413"
"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