Maven and ABCL
evenson at panix.com
Sun Apr 9 10:10:50 UTC 2017
On 4/7/17 17:50, Alan Ruttenberg wrote:
> I'm using :mvn ASDF components and ran into a problem with having multiple
> versions of the same library.
The clearest path forward for conflicting dependencies would be for
JAVA:ADD-TO-CLASSPATH to take an environment which would contain a new,
dynamically added classloader for all java artifacts loaded in scope.
This mechanism is used by Apache Tomcat to introduce a separate
classloader for each Java Servlet instance.
Even though the Tomcat developers presumably thought such a method would
allow some degree of security, they failed. Partly because of the need
for each servlet to use global resources in-process for efficiency gains
(think JDBC), and partly because the security guarantees of the
underlying JVM can be trivially broken (as can be seen by
[abcl-servlet] which boots a swank servlet binding a listening socket
Symbolic bindings in ennvironments via the [five currently missing
methods in ABCL for CtLv2][cltl2-env] could be presumably mimic the
scoping of all possible desired classloaders.
Some abstraction of this sort will be needed to run on Java 9, so we
might as take a stab at supporting both at a profit to ultimate
4.1.1 Modifying the JVM CLASSPATH
The JAVA:ADD-TO-CLASSPATH generic functions allows one to add the
specified pathname or list of
pathnames to the current classpath used by ABCL, allowing the dynamic
loading of JVM objects:
CL-USER > ( add-to-classpath " / path / to / some . jar " )
N.b ADD-TO-CLASSPATH only affects the classloader used by ABCL (the
value of the special
variable JAVA:*CLASSLOADER*. It has no effect on Java code outside ABCL.
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
More information about the armedbear-devel