Re: Maven and ABCL

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][1] which boots a swank servlet binding a listening socket
on localhost).

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
complexity.

[cltl2-env]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html

[1]: https://bitbucket.org/easye/abcl-servlet

[java:add-to-classpath]: :has
""""
4.1 JAVA
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."