skip to content

Which Maven or Gradle plugin does the Apache JMeter project itself publish for running a plan in a build?

level: juniorimportance: should knowfreq 42%

answer

  1. Start from the actual download page contents
  2. Check who owns the Maven groupId
  3. Read JMeter's own feature-list wording
  4. Ask what bin/jmeter needs to exist first

basics

~10 s

None. Apache publishes JMeter only as a binary distribution, apache-jmeter-6.0.0.tgz or .zip, plus library jars under the org.apache.jmeter group. Every Maven, Gradle, Jenkins and container wrapper around it is a third-party community project.

solid answer

~40 s

Apache publishes no build wrapper at all. A JMeter 6.0.0 release is the binary distributions `apache-jmeter-6.0.0.tgz` and `apache-jmeter-6.0.0.zip` (each beside a `.sha512` and a detached PGP `.asc`), the matching source archives, and library jars under the Maven group `org.apache.jmeter` so plugin authors can compile against JMeter. There is no Apache Maven plugin, no Apache Gradle plugin and no Apache container image. JMeter's own front page lists the feature as *"Easy Continuous Integration through 3rd party Open Source libraries for Maven, Gradle and Jenkins"*. The supported unattended entry point is the launcher the distribution already ships, `bin/jmeter`, run with `-n`. Any coordinate, plugin id or image tag you find belongs to a community project with its own cadence, its own tracker and its own pinned JMeter version.

go deeper

for a junior

Recall the shape of the release: two binary archives, matching source archives, and library jars. Nothing in it is a Maven or Gradle plugin, so a build step ultimately calls the same bin/jmeter launcher you use by hand.

for a middle

Explain why a build wrapper cannot be Apache's: the project ships an installation tree and a launcher, and any wrapper has to provision that tree first. Be able to name the groupId test for spotting a community artefact.

for a senior

Show you treat a wrapper as a third-party dependency like any other: pinned, scanned, and with a known fallback. Know that its JMeter version pin is separate from yours and can lag a release.

for a principal

Own the policy for the estate: who verifies the distribution's checksum and signature, where the JMeter version is pinned so it is greppable, and whether the organisation accepts a community project on the path to a release gate.

## What an Apache JMeter release actually contains The artefact list for 6.0.0 is short and fixed: - **Binary distributions** — `apache-jmeter-6.0.0.tgz` and `apache-jmeter-6.0.0.zip`, each published next to a `.sha512` checksum and a detached PGP `.asc` signature. - **Source distributions** — `apache-jmeter-6.0.0_src.tgz` and `apache-jmeter-6.0.0_src.zip`. - **Library jars** published under the Maven group `org.apache.jmeter` (`ApacheJMeter_core` and the protocol modules), so that people writing JMeter components have something to compile against. That is the whole list. There is no Maven *plugin* under that group, no Gradle plugin id owned by the project, and no image pushed by Apache to any container registry. The project says as much in its own feature list, where continuous integration appears as *"Easy Continuous Integration through 3rd party Open Source libraries for Maven, Gradle and Jenkins"* — the load-bearing words being **3rd party**. ## So what is a build step, concretely? Unpack a binary distribution and you get a directory whose sub-directory names must not be renamed: ``` apache-jmeter-6.0.0/bin apache-jmeter-6.0.0/lib apache-jmeter-6.0.0/lib/ext apache-jmeter-6.0.0/lib/junit apache-jmeter-6.0.0/docs apache-jmeter-6.0.0/extras apache-jmeter-6.0.0/licenses ``` `bin/jmeter` is a shell script whose last line is effectively `java $ARGS -jar "$PRGDIR/ApacheJMeter.jar" "$@"`. `JMETER_HOME` defaults to the parent of the `bin` directory it was launched from. So the unattended entry point is the *same* launcher a person uses interactively, with `-n` added and a plan named by `-t`. A build wrapper does not unlock a different execution mode; underneath, it assembles that same command line. That also fixes the runtime requirement on your build image: JMeter 6.x requires **Java 17 or later**, with Java 21 recommended. An agent image pinned to an older JDK cannot run 6.0.0 no matter which wrapper drives it. ## Telling an Apache thing from a community thing Three cheap tests, in order of how often they settle the question: 1. **Read the groupId or plugin id.** Apache's own jars are `org.apache.jmeter:*`. The command-line tool shipped by the jmeter-plugins project, by contrast, is `kg.apc:jmeter-plugins-cmd` — a different organisation entirely. 2. **Ask where the release notes live.** An Apache release is announced on Apache infrastructure and signed with an Apache committer's key; a wrapper's releases are not. 3. **Ask what JMeter version it pins.** A wrapper embeds or downloads a JMeter version of its own choosing, which is why a wrapper can lag a JMeter release by weeks or months. The Custom Thread Groups (Concurrency, Arrivals, Ultimate, Stepping) and the Plugins Manager are in the same category: `jpgc` community components, not part of the Apache download. | Thing | Published by | Consequence for a build | |---|---|---| | `apache-jmeter-6.0.0.tgz` / `.zip` | Apache | You provision and verify it yourself | | `org.apache.jmeter:ApacheJMeter_core` | Apache | Compile-time only; does not run a plan on its own | | A JMeter Maven or Gradle plugin | Community | An extra dependency with its own JMeter version pin | | A JMeter container image | Community | An extra image to trust, scan and pin | ## What this means for a nightly job A nightly job that archives an HTML report as a build artefact can be written either way, and the honest framing is that you are choosing **who owns provisioning**. Take the plain route and your build step downloads and unpacks a distribution, verifies its checksum, drops any extra jars in place, and calls `bin/jmeter -n`; every one of those lines is visible in your repository. Take the wrapper route and those lines move into a community project, along with the decision about which JMeter version they install. Neither is wrong. What *is* wrong is believing the wrapper carries Apache's warranty. It does not: if it breaks on the day JMeter 6.0.0 ships, the fix is on a community tracker, and your fallback is the plain `bin/jmeter -n` step you could have written in the first place.

  • If Apache publishes library jars under org.apache.jmeter, why can a build not just depend on them and run the plan?
    Those jars are the components, not a runner. A run needs a whole JMeter installation: the `bin` directory with its launcher and property files, `lib` for dependency jars and `lib/ext` for components. JMeter is started with `java -jar ApacheJMeter.jar`, which ignores the classpath your build assembled, so a dependency declaration alone reaches nothing.
  • How would you pin the JMeter version a build step runs, without a wrapper to do it for you?
    Fetch a named archive, `apache-jmeter-6.0.0.tgz`, and verify the published `.sha512` before unpacking; keep the version in one variable so the pin is greppable. Cache the unpacked tree on the agent keyed by that version. The version then changes only when someone edits that variable, which is exactly the review you want.

saying these in an interview costs you the question

  • Claims Apache maintains an official JMeter Maven plugin
  • Treats a community container tag as an Apache release artefact
  • Assumes a wrapper tracks new JMeter releases on the day
  • Thinks org.apache.jmeter jars on the build classpath can run a plan
  • Cannot say where the bin/jmeter launcher comes from