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
