3rd party jars - current and proposed

[sebb <se...@gmail.com>]

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.

Re: 3rd party jars - current and proposed

[Philippe Mouawad <ph...@gmail.com>]

@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 <ap...@ya.ru> 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.

Re: 3rd party jars - current and proposed

[Andrey Pokhilko <ap...@ya.ru>]

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.

Re: 3rd party jars - current and proposed

[Philippe Mouawad <ph...@gmail.com>]

I answered in the new thread, great idea !

On Friday, April 8, 2016, Vladimir Sitnikov <si...@gmail.com>
wrote:

> Philippe> The idea was interesting because it makes things rather simple.
>
> What if we take a step back and consider some kind of "JMeter Plugin
> Market"?
>
> For instance:
> 1) Search & install plugins from within JMeter UI
> 2) If loading a test plan that references not yet installed plugins,
> JMeter would be able to suggest installing the required ones
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: 3rd party jars - current and proposed

[Vladimir Sitnikov <si...@gmail.com>]

Philippe> The idea was interesting because it makes things rather simple.

What if we take a step back and consider some kind of "JMeter Plugin Market"?

For instance:
1) Search & install plugins from within JMeter UI
2) If loading a test plan that references not yet installed plugins,
JMeter would be able to suggest installing the required ones

Vladimir

Re: 3rd party jars - current and proposed

[sebb <se...@gmail.com>]

On 8 April 2016 at 20:33, Philippe Mouawad <ph...@gmail.com> wrote:
> On Friday, April 8, 2016, sebb <se...@gmail.com> 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.

Re: 3rd party jars - current and proposed

[Philippe Mouawad <ph...@gmail.com>]

On Friday, April 8, 2016, sebb <se...@gmail.com> 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.
This could be enhanced.


>
> 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.
The folder 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.
I think that the same issue can occur with the other properties


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




-- 
Cordialement.
Philippe Mouawad.