@andrei, closing the pr is too early, afaiu only sebb is against it, the other either want to delay it or improve it.
Thanks for the idea even if. we take it a bit further. On Friday, April 8, 2016, Andrey Pokhilko <[email protected]> wrote: > Okay, thanks for reviewing. I will close the PR. > > Andrey Pokhilko > > On 04/08/2016 06:18 PM, sebb wrote: > > There are currently 3 properties which can be used to augment the > > standard library directories > > (lib, lib/ext, lib/junit) > > > > A) search_paths > > B) user.classpath > > C) plugin_dependency_paths > > > > Directories listed in A or B are added to the internal loader *and* to > > the system property "java.class.path". > > > > Directories listed in C are only added to the internal classloader. > > > > The difference between A and B is that A is used to find plugins that > > are added to the GUI so they can be used in test plans. > > > > This is a very flexible arrangement, because the directories can be > > anywhere, for example a shared folder outside the JMeter installation > > tree. > > > > A recent proposal would add a fixed directory name under lib/3rdparty. > > It and all its subdirectories would be added to the classloader and > classpath. > > > > That can of course be made to work. > > However it is not nearly as flexible as the properties currently allow. > > It does not allow for support jars that should not be added to the > > java classpath > > It does not readily allow for shared directories outside the JMeter > > directory tree. > > > > As far as I can tell, the only benefit is that the entire directory > > subtree is added, not just the initial directory. But there are other > > ways of achieving that. > > -- Cordialement. Philippe Mouawad.
