Hi, When reviewing tests like org.apache.jmeter.testbeans.gui.PackageTest and batchtest I identified an issue with current setup.
./bin/jmeter script puts just a single jar to the classpath which is ApacheJMeter.jar (it uses java -jar ...). Then NewDriver class figures out the location of lib, lib/ext and builds its own classloader with account of the jars in those folders. Issues: 1) PackageTest is trying to search jars for the components, and it uses ClassFinder to do that. ClassFinder tries to check the value of java.class.path property to filter jars here and there which is apparently wrong. 2) batchtest (both local and client-server) adds *all* jars to the classpath when launching NewDriver. This differs from ./bin/jmeter way of launching JMeter, so I think "batch tests" should stick closer to the regular shell scripts. This is something I've corrected in gradle branch otherwise testbeans.gui.PackageTest failed to find classes to test. PS. Frankly speaking, I find ClassFinder a quite fragile way of class loading, however I suggest to postpone that refactoring (e.g. DI-driven or classgraph/classgraph driven). For now I just remove "java.class.path" filtering. Vladimir
