jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: JMeter DSL discussion
Date Fri, 29 Jul 2016 12:07:34 GMT
On Friday, July 29, 2016, Vladimir Sitnikov <>

> >I think it ends up being a dsl anyway no ?
> It ends up being write only DSL.
> We can put whatever makes sense for humans, and do not care
> of the grammar/parsing stuff.
> The set of "printed" values/fields could even depend on the project.
> For instance, some kind of regexp for "exluded/included" header names so
> the output is both concise and useful at the same time.

ok , clear for me.
It could be a first step for a DSL and feasible with not too much work.
I would suggest we build it so that implementing the read is possible as
second step.

> >Or does it in your mind work only from xml => comment
> As I stated in the comment itself, the comment is not supposed
> to be modified. Neither it is supposed to be parsed by JMeter.
> It is there for presentation purposes only, so dump views like "github
> diff"
> can make a basic sense of a file and show a decent diff.

In addition to xml comment in header, I would prefer it to be also in a
separate file generated on save or through command line option or gui

> >If so it does not answer the requirement of some users to be able to
> change
> >the plan without xml format.
> I do understand that "pretty-printer in the comment" does not cover all
> the use cases.
> However, I think pretty printer will be both useful and easy to implement
> at the same time.

I agree

> my concern about language would be:
> > - its popularity ,
> > - its easyness for users
> > - it's easyness to build dsls
> > - its future
> >
> I would add IDE support to the list as well

yes good criterion

> > Groovy is ASF now also and it's already embedded.
> >
> This does not immediately solve "easyness for users" problem of Groovy.
> Have you seen Groovy puzzlers?
> ,
> Take a jsr223 preprocessor that has 4 to 10 lines of groovy code in it, how
> > do you represent it ?
> > That's what I mean.
> > It can make dsl less readable.
> >
> Do you mean "abandon jsr223 in favor of a full blown programming language"?


> Initially I thought you wonder how to add "a jsr223 preprocessor" when
> using some kind of DSL.


> When using a programming language, some kind of IDE is required to craft
> the script.
> I find "http sampler" rather hard to express in DSL so it is readable.
> >
> >
> > look at ruby-jmeter it does a nice job at doing that
> >
> ruby-jmeter implements just a small subset of the options that can be
> configured in JMeter UI.
> It will hardly be that much readable when order options are
> implemented/used (e.g. lots of parameters passed to the application).

I think issue would be the same for all dsls no?

> Vladimir

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message