Philippe>I know work on 3.0 is finished and milamber proposed to be rm right ?
Sorry, I must have missed that. Philippe>But if you want we can discuss later after 3.0 Anytime works for me provided it does not delay 3.0. sebb>They don't care so much about memory footprint as they are not benchmark utils. I agree it is important to keep memory footprint sane, however I'm sure it can easily be done negligible. sebb> There's no particular reason to have it in the core tool. You have no second chance to make the first impression. Suppose a new user installs JMeter. How would (s)he know which plugins are required? Let me exaggerate to make the point more clear: "in order to install JMeter you need to download ant, then perform svn checkout ..., then ant download_jars, then ant install, then find JMeter Plugins in Google, ..." Not having out-of-the-box market makes first-time experience not that smooth. Remember that typical JMeter users are not java programmers. They have no-to-very little idea what the jar file is. Of course, I've made that up, however I do believe that vision is right. Having thought a bit more, I think jmeter-wrapper (named after "gradle wrapper", though not using gradle in any way) script might be useful as well (to have reproducible environment). I mean the following: 1) User (or JMeter) creates a file with text description of exact JMeter version and the versions of installed plugins. For instance: jmeter-installation-versions.xml 2) If someone wants to reproduce exactly the same JMeter installation, he picks that jmeter-installation-versions.xml and executes "./jmeter-wrapper". 3) The wrapper script downloads proper JMeter and plugins versions. Vladimir
