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