<div>Should have responded to this sooner.<br><br>The proposed change is to have a single form in the system definition that deals with all maven dependencies - that's the :mvn-module. It has the most important expressivity available in a POM, namely to list all dependencies, exclusions, and overrides (called managed depencies) which let you specify a specific version for a transitively gathered dependency.</div><div><br></div><div>Having these easily accessible makes the code that asks Maven to resolve the dependencies all at once easy to invoke. </div><div><br></div><div>That part is implemented.</div><div><br></div><div>For the case of managing multiple asdf systems that have maven dependency one way to go forward would be to have resolves dependencies in a system added (and overriding)  managed dependencies in subsequent :mvn module resolution. This has the benefit that you can coordinate version choices across multiple systems by first loading a system definition that sets managed dependencies that stick across all subsequent mvn resolutions.</div><div><br></div><div>There's no guarantee that doing so will be adequate - if the collected set of maven dependencies is fundamentally conflicted you are still screwed. But we can't do anything to prevent that. however in my case that wasn't so and so this strategy solved my issue.</div><div><br></div><div>I think other parts of ABCL have maven dependencies that overlap the ones in LSW. If these load before user code and the versions chosen aren't optimal for downstream use dependencies we might need a mechanism for overriding them (e.g. The resolution during abcl chooses v2.4 but would work with v2.7, but user code might not work with 2.4. To reduce the incidence of such cases we should avoid using version specifications that are restrictive - say only to major version to next major version - and, when possible, defer resolution until needed at runtime. I do that in a couple of cases already. I think in OSGI, and in some code that uses a Java parser library. In those cases the dependencies are not recorded in the system definition. Instead resolve is called only when code that needs is executed. </div><div><br></div><div>Alan</div><div><br><div class="gmail_quote"><div>On Tue, Apr 18, 2017 at 1:57 AM Mark Evenson <<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/18/17 04:14, Alan Ruttenberg wrote:<br>
[…]<br>
> There is OSGI which is able to do this sort of thing, and there is already<br>
> prototype code in JSS to use it. However OSGI, or multiple classloaders,<br>
> needs a fair amount of thought to use correctly, because you can easily<br>
> arrive at situations where compatible classes can't be used because they<br>
> were loaded into different classloaders.<br>
><br>
> The first step is to enable managing dependencies when it *is* possible to<br>
> run without conflicts, as with the :mvn-module I showed above. In this case<br>
> it turns out that the dependencies only *seemed* to conflict. With the<br>
> appropriate use of Maven there is no conflict in this case.<br>
><br>
> The thing that is different in our environment as compared to the standard<br>
> maven situation is that we don't have a central pom for an application that<br>
> gathers all dependencies and resolves them at once. Instead we have<br>
> separate ASDF systems which are loaded independently and yet may have<br>
> intertwined dependencies.<br>
<br>
I agree that incrementally fixing the current situation along the lines<br>
you have prototyped should occur before any dramatic overhaul with<br>
segregated classloaders.<br>
<br>
Currently, I am working towards a [abcl-1.5.0][] next week with the<br>
following priorities:<br>
<br>
1) stabilizing support for Java6 (dropping support for Java5, which in<br>
practice given the absence of an open Java6 VM doesn't exist)<br>
<br>
2)  Resurrect the ABCL-BUILD system to build ABCL from Lisp by<br>
downloading and installing Ant and Maven as needed.<br>
<br>
3)  Provide a restart for failure to find Maven, that will download and<br>
install it in the XDG filesystem.<br>
<br>
[abcl-1.5.0]: <a href="http://abcl.org/trac/milestone/1.5.0" rel="noreferrer" target="_blank">http://abcl.org/trac/milestone/1.5.0</a><br>
<br>
Maybe we can try to squeeze your :MVN-MODULE proposal in as well.  I've<br>
seen [your code that demonstrates the problem][1], but as I understand<br>
it there is no exact code as you need more understanding of the<br>
underlying ASDF mechanisms, right?  If you could take the time in the<br>
next day or so to write up the minimal proposal for your current needs,<br>
I will see what I can do to take a stab at its implementation.<br>
<br>
[1]:<br>
<a href="https://gitlab.common-lisp.net/abcl/abcl/blob/master/t/resolve-multiple-maven-dependencies.lisp" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/abcl/abcl/blob/master/t/resolve-multiple-maven-dependencies.lisp</a><br>
<br>
<br>
--<br>
"A screaming comes across the sky.  It has happened before, but there<br>
is nothing to compare to it now."<br>
</blockquote></div></div>