On Sun, Feb 23, 2020 at 9:03 AM Enrico Olivelli <eolive...@gmail.com> wrote: > > Elliotte, > This is about surefire, we cannot pollute Java classpath of running tests. > The library should be loaded with a special class loader, it would be more > complex than writing a simple hard coded coder/decoder as we already have > in surefire
Absolutely. By using separate class loaders, or better yet a completely different process, you avoid polluting the classpath without shading. By contrast shading with the same class loader does pollute the user's classpath with the shaded code. I'll quote from what IO wrote for https://jlbp.dev/JLBP-1.html The tools we use for Java projects are more often than not themselves written in Java. This includes build systems such as Maven, javac, and Ant; runtime environments such as Tomcat, Hadoop, Beam, and App Engine; and editors such as jEdit, Eclipse, and IntelliJ IDEA. Tools like these should have their own classpaths from which they load their own code. It is critical not to mix the classpath of the tool with the classpath of the product. Dependencies of the tool should not be dependencies of the product. For example, there’s no reason javax.tools.JavaCompiler should appear in the classpath of an MP3 player simply because the player’s source code was compiled by javac. Indeed javac does not transmit its own dependencies into the products it builds, but not all tools are this well behaved. Maven annotation processors such as AutoValue and Animal Sniffer are sometimes declared to be dependencies of the product itself in the pom.xml. Since they are only needed at compile time, they should instead be added to the annotation processor path. When running code from Maven, prefer mvn exec:exec to mvn exec:java. mvn exec:exec uses a completely separate process to run the user’s code while mvn exec:java runs the user’s process in the same virtual machine Maven itself uses. Modern application servers are reasonably good about separating the code they host from their own. However there have been issues in the past where the boundary was not as aggressively maintained. The jre/lib/ext directory in particular has been a common source of hard to debug dependency issues where a different version of a library was loaded instead of the one the user expected. If you are creating a product that runs user supplied code, implement completely separate classpaths for user code and your product’s code. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
