On 8 April 2016 at 20:33, Philippe Mouawad <[email protected]> wrote: > On Friday, April 8, 2016, sebb <[email protected]> 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. > > > there is limitations with those approach, these properties do not work > correctly with relative paths so from one version to the other you need to > update the user.properties.
There are more limitations with the fixed dir name approach. > This could be enhanced. It would be easy enough to update the syntax. e.g. if the path begins with '~', prepend the JMeter home dir. If the path ends with '/*', append the unadorned path and all its subdirectories. > >> >> 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. > > The idea was interesting because it makes things rather simple. Too simple, because it does not allow for separate GUI and support jars. > The folder has an explicit name. The property has an explicit name. > >> >> That can of course be made to work. >> However it is not nearly as flexible as the properties currently allow. > > > Flexibility is good, ease of use is also good >> 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. > > > it's not its intent. The problem is that it basically duplicates existing functionality, but without the flexibility of separate GUI/support jars. > I think that the same issue can occur with the other properties Huh? > >> 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. >> > > It appears the idea was appreciated by some 3rd party developers so it > should not be thrown away like this. The proposal is a possible solution for a specific issue. However there are existing solutions. > I think (as a user of the 3 properties) that they are not that easy to use > for newbies. I myself always have to read again the docs to remember which > separator to use and which property. > some are better for lib dependencies some are better for plugins. > So we need to improve the docs. There would need to be docs for the new directory. === I think the way to approach this is to first determine what the problem is that we are trying to solve. Otherwise the solution likely won't meet all the requirements. As has been evident here. > > > -- > Cordialement. > Philippe Mouawad.
