Impact on modifying the current planning code (was Re: Plans for ASDF 3.3)
Faré
fahree at gmail.com
Thu May 4 17:32:41 UTC 2017
On Thu, May 4, 2017 at 12:01 PM, Alan Ruttenberg <alanruttenberg at gmail.com>
wrote:
> Resolving the maven dependencies in java needs to be a globally done
across
> ASDF systems. If one ASDF system A depends on log4j version 2.1 or higher
> and another B depends on 2.9, and the range of versions is 2.1-2.12 then
if
> A is loaded first there is no way to satisfy the second dependence in a
> predictable way. If you choose the highest available version A can take it
> is too high for B. If you choose the lowest A can choose it is too low for
> B.
>
The best I can see you do with ASDF is as follows:
0- Aim for a single coherent set of jars within a given build, because
otherwise lies madness.
1- Within a given plan-then-perform phase, collect the set of jars and
their version intervals in a :before method on perform-plan that talks to
maven and uses some heuristic to resolve versions.
2- Across plan-then-perform phases of a same build session, record which
versions were loaded, and issue an error if it's incompatible.
3- Across build sessions, remember what version was previously loaded, and
unload/shadow it if it is incompatible (or throw an error if you can't),
and decide whether to keep or upgrade (if possible) if it's compatible.
As to writing a system that solves issues across phases, in your worst
case, your toplevel system would :defsystem-depends-on a system that loads
all the proper versions of all the jar files (or at least the problematic
ones), and then whichever phase causes some version to be loaded will have
been preempted by that first defsystem-depends-on system.
Which reminds me that load-systems should be amended to do only one
plan-then-perform phase for all the requested systems.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Anyone who says he can see through women is missing a lot. — Groucho Marx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20170504/8d5c8ebc/attachment.html>
More information about the asdf-devel
mailing list