> but Groovy IDE support is quite good. Write-only DSL is easy in any language. Implementing proper semantics is hard.
Implementing language-aware autocomplete/validations is much harder than just implementing a DSL that would produce jmx files. By language aware I mean JMeter-aware. For instance: how would you teach IDE to highlight "http sampler cannot be placed under thread group" error if that is groovy DSL? Another example: one of the "samplers" declares a variable, then you need to be able to "use" that variable. You need to be able to navigate to the sampler "which defined that variable". You need to be able to find all the usages of "given regular expression extractor". I'm not talking about groovy variables here. Think of "regexp extractor". It can easily produce lots of JMeter variables behind the scenes (match0, match1, ...). Groovy code would not mention that, would it? How IDE would know that "match0" variable is valid and "abc" is not? language-aware refactorings are even harder. It is not that easy to teach groovy DSL that "transaction controller" can be exchanged with "simple controller". Another point: groovy is a text language. 0) This is a no-go for non-programmers. From my experience, there are lots of JMeter enginers who are not fluent in programming. 1) How would you implement a table in groovy DSL? Just a table with parameters and checkboxes. 2) Http sampler could be very rich in terms of configuration. The text format would be rather bloated, so being able to hide non-relevant notes is a plus for a non-text representation. Vladimir
