jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: About including Groovy
Date Thu, 25 Feb 2016 00:00:44 GMT
Hello,

JMeter is an Apache Software Foundation (ASF) project and follow the 
Apache Way rules [1].

The community can give its opinions before the agreement or decision is 
given. You have to give a little time to get the opinion of each and 
find a consensus.

If consensus is hard to find, a vote like technical type can possibly 
help everyone to agree.

Please, JMeter is an old software with a great history, we must be 
careful about the changes and ensure that they are justified. This is 
because the PMC and Committers must agree to support the new features in 
terms of fixesof anomalies /support the software.

Ifmany PMC and Committers agree to add the Groovy jar into JMeter 
archive, despite the consequences as the size of package, management of 
versions of Groovy / JMeter, etc. then add groovy in JMeter archive.

Milamber

[1] http://www.apache.org/foundation/how-it-works.html

On 24/02/2016 21:12, Andrey Pokhilko wrote:
> If I may...
>
> The role of a leader is a lot to decide for followers what should be
> good for them. That's why people choose leaders - to delegate decision
> making. And good leader is told by making right decisions that ease
> people's life. If you have a lot of people following you, there is
> always some of them who will not agree. But the real measure of success
> is if you help most of them to feel better or not.
>
> Making these decisions is tough. You have to keep up with the risk that
> some people won't like it. But there's no chance for success without the
> risk. Not evolving is the best strategy to not take risks. And it is
> indeed a strategy to stagnate and extinct.
>
> What is the principle of JMeter project? Is it "let's not risk"? Or is
> it "let's help most of people to feel better"?
>
> I'm just a committer, I will accept any answer.
>
> Andrey Pokhilko
>
> On 02/24/2016 11:41 PM, Steven Swor wrote:
>> On Thu, Feb 25, 2016 at 1:52 AM, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 24 February 2016 at 14:21, Philippe Mouawad
>>> <philippe.mouawad@gmail.com> wrote:
>>>> On Wed, Feb 24, 2016 at 1:04 PM, sebb <sebbaz@gmail.com> wrote:
>>>>
>>>>> Let's be clear what this discussion is about.
>>>>>
>>>>> JMeter already supports Groovy.
>>>>> It's not a question of whether Groovy is a good scripting language.
>>>>>
>>>>> The question is whether or not to bundle Groovy with JMeter.
>>>>>
>>>>> The only advantage I can see is that JMeter users don't have to
>>>>> download Groovy in order to use it.
>>>>>
>>>> I don't share your opinion.
>>>> Take the beginner who downloads JMeter, to use Groovy, he must be aware
>>>> that it is available through JSR223 AND that he must download (the
>>> correct
>>>> Groovy Jar, put it in the correct folder, restart JMeter).
>>> This is exactly the advantage I quoted; it does not add a new argument.
>>>
>>>> Meanwhile he can
>>>> screw an existing test plan that used Groovy when he migrates to a new
>>>> JMeter that does not have Groovy.
>>> If he created the plan that uses Groovy, then clearly he already has it.
>>>
>> If he created the plan that uses Groovy, then clearly he is aware that
>> Groovy is a supported option for a JSR223 sampler/procesor/what have you.
>> He may not be aware that Groovy (unlike Beanshell) does not currently come
>> bundled with JMeter.
>>
>>
>>> If it is a 3rd party plan then they ought to document that it uses Groovy.
>>>
>>>> So he selects this element and doesn't find it. Do you think he will go
>>>> further or will he use Beanshell ? (and then face all JAVA 6, 7 , 8
>>> issues
>>>> with Beanshell )
>>>> Read all the blogs on JMeter and you will see how many users still use
>>>> Beanshell because they are not aware  of Groovy or they were not able to
>>>> set it up.
>>> Documentation is the answer here.
>>>
>> No. Intuitive design is the answer here. It means you spend less time
>> maintaining the documentation, and less time fielding questions from
>> clueless newbies who couldn't be bothered to read it.
>>
>>
>>>> Why make it harder for a beginner through and even for experts to use
>>>> Groovy instead of just distributing it ?
>>> Because distribution has disadvantages.
>>>> Groovy is an Apache project ? Why not use it
>>>> Groovy is sexy, useful and sustainable, why be so reluctant with it ?
>>> Again, that is not the question.
>>>
>>>>> The disadvantages are:
>>>>> - additional download size, even if Groovy is not needed
>>>>>
>>>> Groovy add 7mb to bundle , is this an issue nowadays ? I don't think so
>>>>
>>>>> - users will still have to download Groovy if there is a new version
>>>>>
>>>> That's the same problem as with any of our jars in lib.
>>> But Groovy is likely to be changing more rapidly, and adding new features.
>>> Most of the other jars change rarely, and JMeter generally makes use
>>> of part of them.
>>> So there is less need to update them.
>>>
>> Groovy is likely to be changing more rapidly than other jars because it's
>> still under active development, unlike many of the jars currently
>> distributed with JMeter. This is a good thing. JMeter PMC is still free to
>> decide how often they want to update the dependency, but they can do so
>> based on user feedback (bugzilla and mailing lists).
>>
>>>>
>>>>> and JMeter has not yet been updated.
>>>>>
>>>>> It would be useful to know:
>>>>> - what jars are needed?
>>>>>
>>>> groovy-all-2.4.5.jar
>>> Latest version is 2.4.6
>>>
>>>
>>>>> - how large are they?
>>>>>
>>>>> 7mb
>>> i.e. about twice the size of the largest jar.
>>>
>>> This adds aboiut 5% to the total jar size.
>>>
>> The JMeter 2.13 release tarball is 33.7MB in size. The zip version is
>> 35.9MB. You add 6.5% to the total download size by choosing the zip version
>> over the tarball.
>>
>>>>> An alternative approach would be to provide a script to download Groovy.
>>>>> This would solve both the disadvantages I mention.
>>>>>
>>>> Again another external script, + documentation + users aware of it
>>>>> We could even perhaps provide a template to download Groovy using
>>> JMeter.
>>>> In my opinion, too complex , more work for us, more work for user
>>>> This could be a useful sample for people to try.
>>>> I am waiting for other members opinion on this.
>>>>
>>>>> On 23 February 2016 at 09:54, Milamber <milamber@apache.org> wrote:
>>>>>> I think that is a very good idea to add Groovy to JMeter.
>>>>>>
>>>>>>
>>>>>> On 22/02/2016 19:05, Philippe Mouawad wrote:
>>>>>>> Hello,
>>>>>>> +1 for integration as of me.
>>>>>>> Reasons:
>>>>>>> - Make user experience as simple as possible (no need to bundle
>>>>> additional
>>>>>>> libraries and manage configuration
>>>>>>> -jsr223+groovy is the most performing option compared to beanshell
>>>>>>> - as of the scripting I had to do, I always had at some step
to
>>> script
>>>>> and
>>>>>>> used this combination
>>>>>>> - beanshell does not support java6/7/8 sugar syntax
>>>>>>> - groovy is an easy scripting language with the full power of
java +
>>> a
>>>>> lot
>>>>>>> of additional features for xml, json manipulation, jmx ...
>>>>>>> - Groovy is now Apache :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> On Monday, February 22, 2016, Pascal Schumacher <
>>>>> pascalschumacher@gmx.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> when this was last discussed, it was decided to wait till
there is
>>>>>>>> official Apache release (outside of Apache Incubator) of
Groovy.
>>> Groovy
>>>>>>>> 2.4.6 is the first release as a top level project and it
was just
>>>>>>>> released:
>>>>>>>>
>>>>>>>>
>>> http://mail-archives.apache.org/mod_mbox/groovy-users/201602.mbox/%3CCADQzvmnMENGU17_%3D9-_%3DnPDn9Ob3QsXC9iJHChT_zAWo0-CHJg%40mail.gmail.com%3E
>>>>>>>> Cheers,
>>>>>>>> Pascal
>>>>>>>>
>>>>
>>>> --
>>>> Cordialement.
>>>> Philippe Mouawad.
>


Mime
View raw message