Plugins & Plugins Manager

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The reference material consulted while preparing these pages is listed in the section bibliography.

Core JMeter covers HTTP, JDBC, JMS, TCP and a dozen other protocols, but several things load testers ask for every day are not in it: concurrency and arrival-rate thread groups with a step or free-form schedule, a timer that shapes requests per second over time, HTTP/2, WebSocket, Kafka, MQTT and gRPC. They come from plugins. This page explains how JMeter finds plugin code, how to install plugins reproducibly with the JMeter Plugins Manager (in the GUI, on the command line, in Docker and through Maven), how to add a plugin without the manager, and how to judge whether a plugin is safe to build a test on. It ends with a catalogue of the plugins this section uses, with the version, purpose and maintenance status of each.

jmeter-plugins.org is a community project, not an Apache project. The site, the Plugins Manager and the jpgc-* plugins are maintained by Andrey Pokhilko and contributors (the site footer states the Apache 2.0 licence for the project), and the catalogue also lists plugins from third-party vendors (BlazeMeter, independent developers, companies) that are only distributed through it. None of them is released, reviewed or supported by the Apache JMeter project. Treat each plugin as a third-party dependency with its own licence, release cadence and security record.

Versions this page was written against, all re-checked on 2026-10-14:

  • Apache JMeter 5.6.3, the latest release (Java 8 or later, Java 17 or later recommended; the examples use Java 21). JMeter 6.0 is not released; the changes planned for it on the apache/jmeter master branch that matter for plugins are described as planned, not as released behaviour.

  • JMeter Plugins Manager 2.0 (kg.apc:jmeter-plugins-manager:2.0, published to Maven Central on 2026-08-14; its catalogue entry says "Requires JMeter 3.2+") and its command-line runner cmdrunner 2.3.

  • jmeter-maven-plugin 3.8.0 (com.lazerycode.jmeter), the latest release.

  • The gRPC Request plugin 2.0.2 (jmeter-grpc-request, the bakthava continuation of the archived zalopay-oss project).

  • Plugin ids and latest versions as listed in the repository catalogue at https://jmeter-plugins.org/repo/ on the same date. Release dates come from Maven Central or from the plugin’s GitHub releases, whichever hosts the jar.

The classpath properties referred to below (search_paths, user.classpath, plugin_dependency_paths) are described in Installation & Configuration. The plugins named here are used in detail on later pages of this section: the custom thread groups and load shaping page (Concurrency, Ultimate, Arrivals thread groups and the Throughput Shaping Timer), the gRPC load testing page (jmeter-grpc-request) and the CI/CD page (plugins inside a Docker image and a Maven build).

Who publishes what

Source What it provides Where the jars come from Support

Apache JMeter (core)

Everything in the official download: samplers, controllers, timers, listeners, functions.

apache-jmeter-5.6.3.tgz from the Apache download page, verified with SHA-512 and PGP.

The Apache JMeter project (mailing lists, GitHub issues).

jmeter-plugins.org (jpgc-* ids)

The "classic" community plugins: Custom Thread Groups, Throughput Shaping Timer, graphs, PerfMon, Auto-Stop, Dummy Sampler, custom functions and others, plus the Plugins Manager itself.

Mostly Maven Central under the kg.apc group id.

Community: the project’s support forum and GitHub repositories.

Third-party vendors listed in the catalogue

BlazeMeter (bzm-*), independent authors (WebSocket, MQTT, Kafka, gRPC), monitoring vendors (backend listeners).

Maven Central, GitHub release assets or jmeter-plugins.org/files, as each catalogue entry says.

The vendor or author only, through their own repository.

The Plugins Manager catalogue also contains entries for parts of core JMeter (jmeter-core, jmeter-http, jmeter-jdbc, jmeter-jms, jmeter-ftp, jmeter-tcp, jmeter-ldap, jmeter-mail, jmeter-mongodb, jmeter-junit, jmeter-java, jmeter-native, jmeter-components, vendor "JMeter Core Team"). These entries have no downloadable versions: they let the manager recognise core jars that are already installed and, if you want, uninstall rarely used ones to shorten JMeter’s menus.

Source: JMeter Plugins Manager (JMeter Plugins wiki), JMeter Plugins repository catalogue

The plugin model

Where plugin code lives

A JMeter plugin is a jar file that contains test elements (samplers, controllers, timers, listeners, config elements, pre- and post-processors, assertions, thread groups) or functions. JMeter’s rules for jars are:

Location What goes there

lib/ext

Plugin jars: JMeter scans them for test elements and functions. The Plugins Manager jar itself goes here too.

lib

Libraries that plugins depend on (for example jmeter-plugins-cmn-jmeter, kafka-clients) and utility jars such as JDBC drivers. Libraries are not scanned for components.

search_paths

Extra directories or jars searched for plugin classes, in addition to lib/ext. Separated by ;.

user.classpath, plugin_dependency_paths

Extra locations for libraries; plugin_dependency_paths adds them to JMeter’s internal class loader only and is the manual’s preferred choice for plugin dependencies.

Restart JMeter after adding or removing any jar: the class loaders are built once at start-up. A test plan that names a class which is not on the classpath cannot be loaded at all, in the GUI or in CLI mode, so a missing plugin is a hard failure, not a warning.

Source: Getting Started: Classpath configuration (User Manual)

How JMeter 5.6 discovers plugin classes

Until 5.5, JMeter found test elements by scanning every class in lib/ext (and search_paths) for subclasses of the relevant interfaces. JMeter 5.6 introduced Java’s ServiceLoader for this: the changes list for 5.6 says "Use Java’s ServiceLoader for loading plugins instead of classpath scanning. It enables faster startup" (PR 5885). A plugin that wants to be found this way declares its classes in META-INF/services files inside its jar.

Older plugins do not have those files, so 5.6.3 does both. Reading the 5.6.3 sources (JMeterUtils.loadServicesAndScanJars and ClassFinder), JMeter first loads everything the ServiceLoader finds and then still scans the jars in lib/ext and search_paths for further implementations, skipping classes it already loaded. A jar whose manifest declares JMeter-Skip-Class-Scanning: true is skipped by that scan, which is how a modern plugin tells JMeter that its ServiceLoader metadata is complete. In 5.6.3 the attribute only applies to the lookups of functions, Java Request clients and Backend Listener clients; samplers, TestBeans and GUI classes are still found by scanning lib/ext (the extending page shows the effect). In practice this means:

  • old jpgc-* plugins built years before 5.6 keep working in 5.6.3;

  • every jar in lib/ext still costs start-up time, which is one more reason to install only what a plan uses;

  • the scanning API is marked deprecated since 5.6, so plugin authors should ship META-INF/services files.

Source: Changes History (Version 5.6), JMeterUtils.java at rel/v5.6.3 (apache/jmeter)

What a plugin looks like inside a .jmx

A .jmx file records each element with its guiclass and testclass. For a plugin element these are the plugin’s class names, so the plan itself tells you which plugins it needs. This fragment is the Bookshelf stress profile with the Concurrency Thread Group from jpgc-casutg (its fields are explained on the custom thread groups page):

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.6.3">
  <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="bookshelf-stress">
      <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments">
        <collectionProp name="Arguments.arguments"/>
      </elementProp>
    </TestPlan>
    <hashTree>
      <com.blazemeter.jmeter.threads.concurrency.ConcurrencyThreadGroup
          guiclass="com.blazemeter.jmeter.threads.concurrency.ConcurrencyThreadGroupGui"
          testclass="com.blazemeter.jmeter.threads.concurrency.ConcurrencyThreadGroup" testname="Search users (stepped)">
        <elementProp name="ThreadGroup.main_controller" elementType="com.blazemeter.jmeter.control.VirtualUserController"/>
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <stringProp name="TargetLevel">${__P(threads,50)}</stringProp>
        <stringProp name="RampUp">${__P(rampup,60)}</stringProp>
        <stringProp name="Steps">5</stringProp>
        <stringProp name="Hold">600</stringProp>
        <stringProp name="LogFilename"></stringProp>
        <stringProp name="Iterations"></stringProp>
        <stringProp name="Unit">S</stringProp>
      </com.blazemeter.jmeter.threads.concurrency.ConcurrencyThreadGroup>
      <hashTree/>
    </hashTree>
  </hashTree>
</jmeterTestPlan>

Worked numbers: 50 threads reached in 5 steps over 60 s means 10 more threads every 12 s; the 600 s hold then gives the same 660 s total as the core Thread Group profile used elsewhere in this section (60 s ramp-up plus a 10-minute hold).

Opening this file on a JMeter without jpgc-casutg fails because com.blazemeter.jmeter.threads.concurrency.ConcurrencyThreadGroup cannot be resolved. The Plugins Manager’s install-for-jmx command, shown below, reads exactly these class names to work out which plugin to install.

Source: Concurrency Thread Group (JMeter Plugins wiki), JMeter Plugins repository catalogue (the componentClasses of jpgc-casutg)

What plugins cost on the load generator

Plugins run inside the same JVM as the virtual users, so their cost is your test’s cost:

  • Start-up and memory. Every jar in lib/ext is scanned at start-up, and every library in lib is loaded into the same heap. A generator image with "everything installed" starts slower and has a larger class footprint than one with the four plugins the plan uses.

  • Listeners and graphs. The jpgc-graphs-* listeners are GUI listeners. Like View Results Tree, they keep data in memory to draw it, so they belong in a debugging session, not in a load run; disable them or remove them from the plan before running in CLI mode.

  • Samplers with their own client stacks. HTTP/2, gRPC, Kafka and MQTT plugins bring their own network libraries (Jetty, Netty, kafka-clients) with their own thread pools and buffers. Size the heap for them and watch generator CPU as closely as for the core HTTP Request.

  • Monitoring plugins. PerfMon collects server metrics through a separate agent and plots them in the GUI; it adds its own sampling traffic and memory. Real-time monitoring with the core Backend Listener is covered on a later page.

How the Plugins Manager installs a plugin

The Plugins Manager is itself a plugin. When you open it, it downloads the catalogue (a JSON document), compares it with the jars it finds on JMeter’s classpath, and works out which plugins are installed, which can be installed and which can be upgraded. When you apply changes it resolves dependencies between plugins, downloads the plugin jars and their libraries to temporary files, and hands the actual file moves to a separate helper process, because JMeter cannot replace jars it has open. In the GUI, that process then restarts JMeter.

flowchart LR A["Options menu: Plugins Manager"] --> B["Read catalogue JSON (jpgc.repo.address)"] B --> C{"Cached copy in pmgr_cache still valid?"} C -- yes --> D["Use cached catalogue"] C -- no --> E["Download catalogue from jmeter-plugins.org or a private repository"] E --> D D --> F["Tick plugins and versions, review changes"] F --> G["Resolve dependencies: plugin ids plus libs"] G --> H["Download plugin jars and library jars to temp files"] H --> I["Helper process moves files"] I --> J["Plugin jars into lib/ext"] I --> K["Library jars into lib"] I --> L["Removed jars into a jpgc-deleted-jars temp folder"] J --> M["Restart JMeter"] K --> M L --> M

Details that matter when something goes wrong, taken from the Plugins Manager 2.0 sources:

  • Plugin jars are written next to the Plugins Manager jar (normally lib/ext); libraries are written to its parent directory (lib) when it is writable.

  • Uninstalled jars are not deleted but moved to a temporary folder whose name starts with jpgc-deleted-jars-; the manager logs the folder name, so an accidental uninstall can be undone by moving the jars back.

  • The manager refuses to apply changes when it cannot write to JMeter’s directories ("Have no write access for JMeter directories, not possible to use Plugins Manager"). Install JMeter in a directory the user running it owns.

  • The catalogue is cached in pmgr_cache under the java.io.tmpdir directory; without server cache headers a cached copy is treated as valid for one hour.

Source: JMeter Plugins Manager (JMeter Plugins wiki), jmeter-plugins-manager source (GitHub)

Installing the Plugins Manager

In the GUI

  1. Download the Plugins Manager jar. The install page links to https://jmeter-plugins.org/get/, which always serves the latest version; for a reproducible install take the versioned jar from Maven Central instead (below).

  2. Put the jar into lib/ext of your JMeter installation.

  3. Restart JMeter.

  4. Open Options → Plugins Manager. A toolbar button with the same function is added as well.

export JMETER_HOME=/opt/apache-jmeter-5.6.3

# the Plugins Manager itself, pinned to 2.0
curl -fL -o "$JMETER_HOME/lib/ext/jmeter-plugins-manager-2.0.jar" \
  https://repo1.maven.org/maven2/kg/apc/jmeter-plugins-manager/2.0/jmeter-plugins-manager-2.0.jar

# its command-line runner, needed for PluginsManagerCMD (see below)
curl -fL -o "$JMETER_HOME/lib/cmdrunner-2.3.jar" \
  https://repo1.maven.org/maven2/kg/apc/cmdrunner/2.3/cmdrunner-2.3.jar

ls "$JMETER_HOME/lib/ext" | grep plugins-manager

Output:

jmeter-plugins-manager-2.0.jar

Maven Central publishes a .sha1 (and .md5) file next to each jar, so the download can be checked the same way as the JMeter archive on the installation page.

Source: Installing Plugins (JMeter Plugins), jmeter-plugins-manager README (GitHub)

The Plugins Manager dialog

Element What it does

Options → Plugins Manager menu item and toolbar button

Open the dialog. When any installed plugin has a newer version, the label reads "Plugins Manager (has upgrades)".

Installed Plugins tab

Every plugin the manager recognises on the classpath, core JMeter parts included. Removing a tick schedules the plugin for uninstall.

Available Plugins tab

Every catalogue entry that is not installed. Setting a tick schedules the plugin for installation.

Upgrades tab

Installed plugins with a newer version. All of them are pre-selected for upgrade; upgradable plugins are also shown in italics on the Installed tab.

Search…​ field

Filters the list of the current tab by name.

Description pane

The selected plugin’s description, vendor and a link to its documentation (the catalogue’s helpUrl).

Version: drop-down

Chooses which catalogue version to install or upgrade to. This is how you pin an older version in the GUI.

Review Changes pane

Lists every change that Apply will make, including plugins that are uninstalled or installed because of dependencies. Read it before applying.

Apply Changes and Restart JMeter button

Downloads, hands the file moves to the helper process and restarts JMeter. Save the open plan first.

Toggle All (right-click on a list)

Ticks or unticks every item in the list. Slow on the Available tab, and rarely what you want.

The wiki suggests one more use of the dialog: uninstalling core parts you never use (for example jmeter-ldap or jmeter-ftp) to tidy the Add menus. On a load generator that runs one plan, a smaller installation also starts faster. Never uninstall jmeter-core or a component your plans use.

An empty dialog almost always means that the manager cannot reach the catalogue, usually because a proxy is needed. New plugins that do not appear mean a stale cache: delete the pmgr_cache folder in the java.io.tmpdir directory and reopen the dialog.

Source: JMeter Plugins Manager (JMeter Plugins wiki)

Proxy, timeout and TLS

The manager respects JMeter’s proxy settings. The wiki recommends passing them through JVM_ARGS rather than editing properties files; credentials use the http.proxyUser and http.proxyPass properties:

JVM_ARGS="-Dhttps.proxyHost=proxy.example.internal -Dhttps.proxyPort=8080" "$JMETER_HOME/bin/jmeter"
Property Default Meaning

jpgc.repo.address

https://jmeter-plugins.org/repo/

Catalogue location(s), separated by ;. Read as a JMeter property, falling back to a JVM system property of the same name.

jpgc.repo.sendstats

true

Send anonymous usage statistics (see below). Set to false to opt out.

jpgc.repo.timeout

30000 (ms)

Network timeout for the catalogue and downloads in the GUI. The wiki suggests 60000 in user.properties when "Connection Timed Out" errors appear.

https.proxyHost, https.proxyPort, http.proxyUser, http.proxyPass

unset

Proxy for the manager’s downloads, passed as JVM system properties.

The defaults are taken from the 2.0 source; the wiki gives the property names and the suggested timeout value. For the "trustAnchors parameter must be non-empty" TLS error, the wiki suggests pointing javax.net.ssl.trustStore at the JDK’s cacerts file through JVM_ARGS.

Source: Plugins Manager Network Configuration (JMeter Plugins wiki)

Command-line installs for CI and Docker

A load generator in CI or in a container has no GUI. The Plugins Manager ships a command-line tool for that case, PluginsManagerCMD, which runs through cmdrunner.

Preparing the command-line tool

The wiki lists two prerequisites:

  1. cmdrunner in lib. The wiki still names cmdrunner-2.0.jar, but the PluginsManagerCMD.sh script that Plugins Manager 2.0 generates runs lib/cmdrunner-2.3.jar, and the 2.0 catalogue entry depends on cmdrunner>=2.3. Install 2.3, as in the download step above.

  2. PluginsManagerCMD.sh (or .bat) in bin. Generate both scripts with the installer class shipped inside the manager jar:

java -cp "$JMETER_HOME/lib/ext/jmeter-plugins-manager-2.0.jar" \
  org.jmeterplugins.repository.PluginManagerCMDInstaller
ls "$JMETER_HOME/bin" | grep PluginsManagerCMD

Output:

PluginsManagerCMD.bat
PluginsManagerCMD.sh

The generated Unix script is one line: it runs Java headless with $JVM_ARGS and starts org.jmeterplugins.repository.PluginManagerCMD through lib/cmdrunner-2.3.jar, so proxy settings go into JVM_ARGS exactly as for the GUI.

Source: Plugins Manager from Command-Line (JMeter Plugins wiki)

Commands

The syntax is PluginsManagerCMD <command> [<params>]. Plugin lists are comma-separated ids, and id=version pins a version.

Command Parameters Effect

help

none

Prints the usage text.

status

none

Prints the installed plugins as [id=version, ...], core parts included.

available

none

Prints every catalogue entry that is not installed with its versions, newest first.

upgrades

none

Prints installed plugins that have a newer version as [id=version, ...], or "There is nothing to update."

install

id[=version],id[=version]

Installs (or upgrades or downgrades to) the given plugins and their dependencies.

install-all-except

id,id

Installs every available plugin except the listed ones. Avoid on load generators: it installs everything.

install-for-jmx

path(s) of .jmx files, comma-separated

Analyses the plans, finds the classes they reference that are not installed, and installs the plugins whose catalogue entries declare those classes.

uninstall

id,id

Uninstalls the given plugins (core parts such as jmeter-ftp included).

Command-line changes are applied without a restart: there is no JMeter process to restart. The file moves are still done by a helper process that the command starts, so check the result with status (or by listing lib/ext) before running a test.

Example: the Bookshelf generator

The Bookshelf plans use the Concurrency Thread Group (jpgc-casutg), the Throughput Shaping Timer (jpgc-tst), the Dummy Sampler for debugging extractors (jpgc-dummy) and, for bookshelf-grpc.jmx, the gRPC Request sampler (jmeter-grpc-request). Pin all four:

cd "$JMETER_HOME"
bin/PluginsManagerCMD.sh install jpgc-casutg=3.1.1,jpgc-tst=2.6,jpgc-dummy=0.4,jmeter-grpc-request=2.0.2
bin/PluginsManagerCMD.sh status

The last line of status lists what is installed (abridged here; the core parts appear with the JMeter version):

[jpgc-casutg=3.1.1, jpgc-tst=2.6, jpgc-dummy=0.4, jmeter-grpc-request=2.0.2, jpgc-plugins-manager=2.0, jmeter-core=5.6.3, jmeter-http=5.6.3, ...]

Alternatively, let the plans decide:

bin/PluginsManagerCMD.sh install-for-jmx /work/plans/bookshelf-load.jmx,/work/plans/bookshelf-grpc.jmx

install-for-jmx is convenient but installs the latest version of each plugin it finds, so it is not reproducible over time. Use it once to discover the ids, then pin them with install id=version in scripts.

Source: Plugins Manager from Command-Line (JMeter Plugins wiki)

Example: a Docker image with pinned plugins

There is no official Apache JMeter image. This Dockerfile builds a generator from the official binary distribution and installs the Plugins Manager and the Bookshelf plugins at fixed versions, so every container runs the same code:

FROM eclipse-temurin:21-jre

ARG JMETER_VERSION=5.6.3
ARG PMGR_VERSION=2.0
ARG CMDRUNNER_VERSION=2.3
ENV JMETER_HOME=/opt/apache-jmeter-${JMETER_VERSION}
ENV PATH="${JMETER_HOME}/bin:${PATH}"

RUN apt-get update && apt-get install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/* \
 && curl -fL https://dlcdn.apache.org/jmeter/binaries/apache-jmeter-${JMETER_VERSION}.tgz | tar -xz -C /opt \
 && curl -fL -o ${JMETER_HOME}/lib/ext/jmeter-plugins-manager-${PMGR_VERSION}.jar \
      https://repo1.maven.org/maven2/kg/apc/jmeter-plugins-manager/${PMGR_VERSION}/jmeter-plugins-manager-${PMGR_VERSION}.jar \
 && curl -fL -o ${JMETER_HOME}/lib/cmdrunner-${CMDRUNNER_VERSION}.jar \
      https://repo1.maven.org/maven2/kg/apc/cmdrunner/${CMDRUNNER_VERSION}/cmdrunner-${CMDRUNNER_VERSION}.jar \
 && java -cp ${JMETER_HOME}/lib/ext/jmeter-plugins-manager-${PMGR_VERSION}.jar \
      org.jmeterplugins.repository.PluginManagerCMDInstaller \
 && echo "jpgc.repo.sendstats=false" >> ${JMETER_HOME}/bin/jmeter.properties \
 && PluginsManagerCMD.sh install jpgc-casutg=3.1.1,jpgc-tst=2.6,jpgc-dummy=0.4,jmeter-grpc-request=2.0.2 \
 && sleep 5 && PluginsManagerCMD.sh status

WORKDIR /work
ENTRYPOINT ["jmeter"]

Build it and run the smoke profile against the local Bookshelf API:

docker build -t bookshelf-jmeter:5.6.3 .
docker run --rm --network host -v "$PWD:/work" bookshelf-jmeter:5.6.3 \
  -n -t bookshelf-load.jmx -Jthreads=1 -Jrampup=1 -Jduration=60 -l results.jtl

Three details in this file are deliberate:

  • The SHA-512 check is omitted for brevity. In a real image, verify the JMeter archive as shown on the installation page before unpacking it.

  • Statistics are switched off in jmeter.properties. Normally properties belong in user.properties, but the 2.0 source of the command-line tool loads only bin/jmeter.properties before it reads jpgc.repo.sendstats, so a value in user.properties would not reach PluginsManagerCMD. Appending one line in an image build is a reproducible change, not a hand edit. In the GUI, user.properties works as usual.

  • The sleep before status gives the helper process that moves the jars time to finish inside the same RUN step; the status output in the build log is the record of what the image contains.

Source: Plugins Manager from Command-Line (JMeter Plugins wiki), Download Apache JMeter

Configuration

Pinning versions

The catalogue changes without notice: new versions appear, and occasionally the distribution of a plugin moves to a different maintainer (as happened to jmeter-grpc-request, see the catalogue below). Results are only comparable when the generator runs the same plugin code, so pin versions everywhere:

  • in scripts and Dockerfiles, always use install id=version, never a bare install id or install-for-jmx;

  • keep the list in one place (a build argument, a plugins.txt file read by the build, or the Maven pom.xml) and review changes to it like any dependency upgrade;

  • record the output of PluginsManagerCMD.sh status with each test’s results, next to the JMeter and Java versions;

  • in the GUI, choose the version in the Version: drop-down rather than accepting the pre-selected upgrades;

  • make sure every node of a distributed test has the same plugins at the same versions; the distributed testing page explains why every node must be identical.

A private repository

jpgc.repo.address accepts several catalogue URLs separated by ;. The first is normally the public catalogue; the others are your own. When two catalogues declare the same plugin id, the first one wins:

# user.properties
jpgc.repo.address=https://jmeter-plugins.org/repo/;https://repo.example.internal/jmeter/plugins-repo.json

A catalogue is a JSON array of plugin entries. This entry publishes a hypothetical internal function library used by the Bookshelf team, in the same shape as the public entries:

[
  {
    "id": "bookshelf-functions",
    "name": "Bookshelf test functions",
    "description": "Internal functions for Bookshelf test data",
    "helpUrl": "https://repo.example.internal/jmeter/bookshelf-functions.html",
    "vendor": "Bookshelf QA",
    "markerClass": "org.example.bookshelf.jmeter.IsbnFunction",
    "componentClasses": ["org.example.bookshelf.jmeter.IsbnFunction"],
    "versions": {
      "1.0.0": {
        "changes": "First release",
        "downloadUrl": "https://repo.example.internal/jmeter/bookshelf-functions-1.0.0.jar",
        "depends": ["jmeter-core"],
        "libs": {}
      }
    }
  }
]

The fields mirror the public catalogue: markerClass is the class the manager looks for to decide whether the plugin is installed, componentClasses lists the classes install-for-jmx matches against, depends names other plugin ids and libs maps library names to jar URLs that are installed into lib. The wiki says the JSON must satisfy the catalogue’s format requirements and points plugin authors to the project’s forum for details; the public catalogue is the best reference for valid entries.

For an air-gapped network, mirror the public catalogue and the jars it points to on an internal server and list only the internal URL. The 2.0 source also accepts a path to a local JSON file as the value of jpgc.repo.address (a single file, not a list); this is not described in the wiki.

The command-line tool reads jpgc.repo.address from jmeter.properties or, failing that, from a JVM system property, so in CI pass it as JVM_ARGS="-Djpgc.repo.address=...".

Source: JMeter Plugins Manager: Plugins Sources Configuration (JMeter Plugins wiki), JMeter Plugins repository catalogue

Usage statistics

By default the Plugins Manager sends anonymous information to jmeter-plugins.org: the full JMeter version, the list of installed plugins with their versions, and an anonymous unique id for the installation. The wiki states that no personally identifiable information is sent and that the statistics are published on the site’s statistics page. Organisations that do not allow outbound telemetry from test infrastructure should opt out:

# user.properties (GUI); bin/jmeter.properties for the command-line tool, see the Docker example
jpgc.repo.sendstats=false

In the 2.0 source, install-for-jmx never sends statistics, while install, uninstall and install-all-except do unless the property is false.

Source: JMeter Plugins Manager: Usage Statistics Collected (JMeter Plugins wiki)

Checking plugin versions from a test

The Plugins Manager exposes two static methods that scripts can call. They are useful in a setUp Thread Group that logs the generator’s plugin set, or that fails the test early when a required plugin is missing:

// JSR223 Sampler (Groovy) in a setUp Thread Group
import org.jmeterplugins.repository.PluginManager

def casutg = PluginManager.getPluginStatus('jpgc-casutg')   // e.g. "3.1.1", or null if not installed
log.info('Plugins on this generator: ' + PluginManager.getAllPluginsStatus())
if (casutg == null) {
    SampleResult.setSuccessful(false)
    SampleResult.setResponseMessage('jpgc-casutg is not installed on this load generator')
}

Scripting with JSR223 elements and the log and SampleResult bindings is covered in Scripting with JSR223 & Groovy.

Source: Plugins Manager from Command-Line: Using from BeanShell or JSR223 (JMeter Plugins wiki)

Adding plugins without the manager

With the jmeter-maven-plugin

The jmeter-maven-plugin builds its own JMeter installation under target and runs the plans in src/test/jmeter. It does not use the Plugins Manager; plugins are Maven artifacts listed in <jmeterExtensions> and copied into the generated lib/ext. Three configuration elements decide what ends up on the classpath:

Element Default Meaning

<jmeterExtensions>

empty

groupId:artifactId:version artifacts copied into lib/ext.

<downloadExtensionDependencies>

true

Also copy the transitive dependencies of the extensions into lib/ext.

<excludedArtifacts>

empty

groupId:artifactId artifacts to leave out when dependencies are resolved.

<testPlanLibraries>

empty

Artifacts copied into lib (libraries, drivers).

<jmeterVersion>

5.6.2 in 3.8.0

The JMeter version the plugin builds.

The wiki’s own example sets <downloadExtensionDependencies> to false because some plugins "use some broken dependencies". The jpgc-* POMs show why: jmeter-plugins-casutg 3.1.1 declares a compile dependency on ApacheJMeter_core 5.2.1, and jmeter-plugins-cmn-jmeter on ApacheJMeter_core 2.13, so resolving transitively would copy old JMeter core jars next to the current ones. The reliable pattern is to switch transitive resolution off and list exactly the jars the Plugins Manager catalogue would install, the plugin plus its libs. For the Bookshelf plans that is:

<plugin>
  <groupId>com.lazerycode.jmeter</groupId>
  <artifactId>jmeter-maven-plugin</artifactId>
  <version>3.8.0</version>
  <executions>
    <execution>
      <id>configuration</id>
      <goals>
        <goal>configure</goal>
      </goals>
    </execution>
    <execution>
      <id>jmeter-tests</id>
      <goals>
        <goal>jmeter</goal>
      </goals>
    </execution>
    <execution>
      <id>jmeter-check-results</id>
      <goals>
        <goal>results</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <jmeterVersion>5.6.3</jmeterVersion>
    <jmeterExtensions>
      <artifact>kg.apc:jmeter-plugins-casutg:3.1.1</artifact>
      <artifact>kg.apc:jmeter-plugins-tst:2.6</artifact>
      <artifact>kg.apc:jmeter-plugins-dummy:0.4</artifact>
      <!-- library that the jpgc plugins need, as listed in their catalogue entries -->
      <artifact>kg.apc:jmeter-plugins-cmn-jmeter:0.7</artifact>
    </jmeterExtensions>
    <downloadExtensionDependencies>false</downloadExtensionDependencies>
  </configuration>
</plugin>

After mvn verify, the generated lib/ext contains exactly those jars:

mvn -q verify
ls target/*/jmeter/lib/ext | grep -E 'casutg|tst|dummy|cmn'
jmeter-plugins-casutg-3.1.1.jar
jmeter-plugins-cmn-jmeter-0.7.jar
jmeter-plugins-dummy-0.4.jar
jmeter-plugins-tst-2.6.jar

The plugin creates the JMeter installation in a generated (UUID-named) folder under target, as the wiki shows, hence the wildcard. The library jar lands in lib/ext rather than lib here; that works because lib/ext is also on the classpath.

Plugins that are not on Maven Central. At the time of writing, the 2.0.x releases of jmeter-grpc-request are published only as GitHub release assets (the catalogue’s downloadUrl points there), and bzm-http2 3.x likewise; Maven Central holds only com.blazemeter:jmeter-bzm-http2 up to 1.4. Download the release jar, install it into your repository manager (or the local repository with Maven’s standard install:install-file goal) under coordinates of your choosing, and list those coordinates in <jmeterExtensions>.

The jmeter-maven-plugin itself, its goals and the CI pipeline around it are covered on the CI/CD page of this section; Performance Testing with JMeter in the Spring Boot reference shows the same plugin in a Spring Boot project.

Source: Adding/Excluding libraries to/from the classpath (jmeter-maven-plugin wiki), Specifying JMeter Version (jmeter-maven-plugin wiki)

Manual jar install

Without network access from the generator, or for a one-off check, install a plugin by hand. The catalogue entry tells you exactly which files the Plugins Manager would install: downloadUrl is the plugin jar for lib/ext, libs are the libraries for lib, and depends lists other plugin ids that must be installed first. Read them with jq:

curl -fsSL https://jmeter-plugins.org/repo/ -o jpgc-repo.json
jq '.[] | select(.id=="jpgc-tst") | .versions["2.6"]' jpgc-repo.json

Output:

{
  "changes": "Added support for multiple load_profile properties",
  "downloadUrl": "https://repo.maven.apache.org/maven2/kg/apc/jmeter-plugins-tst/2.6/jmeter-plugins-tst-2.6.jar",
  "libs": {
    "jmeter-plugins-cmn-jmeter": "https://repo.maven.apache.org/maven2/kg/apc/jmeter-plugins-cmn-jmeter/0.7/jmeter-plugins-cmn-jmeter-0.7.jar"
  }
}

Then copy the files and restart JMeter:

curl -fL -o "$JMETER_HOME/lib/ext/jmeter-plugins-tst-2.6.jar" \
  https://repo.maven.apache.org/maven2/kg/apc/jmeter-plugins-tst/2.6/jmeter-plugins-tst-2.6.jar
curl -fL -o "$JMETER_HOME/lib/jmeter-plugins-cmn-jmeter-0.7.jar" \
  https://repo.maven.apache.org/maven2/kg/apc/jmeter-plugins-cmn-jmeter/0.7/jmeter-plugins-cmn-jmeter-0.7.jar

Manual installs have two classic failure modes:

  • Two versions of the same jar. Copying jmeter-plugins-tst-2.6.jar next to an older jmeter-plugins-tst-2.5.jar leaves both on the classpath, and which class wins is undefined. Remove the old jar first.

  • A library in the wrong place, or missing. A plugin without its libs fails when the element is added or the plan is loaded, typically with a NoClassDefFoundError. Libraries belong in lib (or plugin_dependency_paths), not in lib/ext, when you install by hand.

If the Plugins Manager is installed as well, it recognises manually copied jars through their markerClass, so the manual install shows up on the Installed Plugins tab.

Source: JMeter Plugins repository catalogue, Getting Started: Classpath configuration (User Manual)

Catalogue of useful plugins

The table lists the plugins this section refers to, with the id to use in PluginsManagerCMD, the latest version in the catalogue, its purpose and its maintenance status on 2026-10-14. "Last release" is the publication date of that version on Maven Central or on the plugin’s GitHub releases page; a plugin that has not changed for years is not necessarily broken, but nobody is fixing it either.

Plugin Id Version Purpose Maintenance status

Plugins Manager

jpgc-plugins-manager

2.0

Installs, upgrades and removes plugins; GUI dialog and PluginsManagerCMD.

Active: 2.0 released 2026-08. Requires JMeter 3.2 or later and cmdrunner 2.3.

Custom Thread Groups

jpgc-casutg

3.1.1

Concurrency, Ultimate, Stepping, Arrivals and Free-Form Arrivals thread groups.

Maintained: 3.1.1 released 2025-05. The Stepping Thread Group is superseded by the Concurrency Thread Group.

Throughput Shaping Timer

jpgc-tst

2.6

Shapes requests per second over time with a load_profile schedule; provides the __tstFeedback function.

Stable: 2.6 released 2023-07 (multiple load_profile properties).

3 Basic Graphs

jpgc-graphs-basic

2.0

Average Response Time, Active Threads and Successful/Failed Transactions graphs in the GUI.

Unchanged since 2016. GUI-only; use the HTML dashboard for reports.

PerfMon (Servers Performance Monitoring)

jpgc-perfmon

2.1

Collects CPU, memory, disk and network metrics from a ServerAgent started on the target machine.

Legacy: unchanged since 2016. Prefer the Backend Listener with server-side metrics (Prometheus, Actuator).

Auto-Stop Listener

jpgc-autostop

0.3

Stops the test when runtime KPIs (response time, errors, latency) cross a threshold.

Maintained: 0.3 released 2025-06 (response-time percentile criterion).

Dummy Sampler

jpgc-dummy

0.4

Generates a sample with the response you specify, without network traffic; for debugging extractors and logic.

Stable: unchanged since 2019.

Custom JMeter Functions

jpgc-functions

2.2

Extra functions such as __chooseRandom, __env, __isDefined, __MD5, __base64Encode, __strReplace.

Stable: 2.2 released 2022-10. Check core functions first; many needs are covered by __groovy and __P.

Inter-Thread Communication

jpgc-fifo

0.2

Global string queues for passing values between threads and thread groups.

Unchanged since 2016.

JSON/YAML Plugins (deprecated)

jpgc-json

2.7

JSONPath extractor and assertion, plus YAML variants.

Deprecated in the catalogue "in favor of core JMeter 4.0+": use the core JSON Extractor, JSON JMESPath Extractor and JSON Assertion. Bundles old json-path and json-smart jars.

jpgc - Standard Set

jpgc-standard

2.0

Virtual package that installs jpgc-dummy, jpgc-casutg, jpgc-tst, jpgc-graphs-basic, jpgc-ffw, jpgc-fifo, jpgc-perfmon and jpgc-functions.

Convenience only; install the individual plugins you need instead.

BlazeMeter - HTTP Plugin

bzm-http2

3.2.0

bzm - HTTP Sampler for HTTP/1.1, HTTP/2 and HTTP/3 (QUIC), plus an HTTP Async Controller.

Active: 3.2.0 released 2026-08-25 (GitHub). Requires Java 17 or later; depends on core jmeter-http. The older bzm-http2-legacy (1.6.2) is deprecated.

WebSocket Samplers by Peter Doornbosch

websocket-samplers

1.3.2

Six samplers for WebSocket connections, including a request-response sampler.

Maintained: 1.3.2 released 2026-01 (Maven Central). The other WebSocket entry, websocket-sampler by Maciej Zaleski, offers only a 1.0.2-SNAPSHOT build and is not maintained.

DI KafkaMeter

di-kafkameter

1.3

Kafka producer and consumer samplers and configuration elements.

Low activity: 1.3 released 2024-09. No licence file at the repository root when checked. The older kafkameter (0.2.0) entry is abandoned.

MQTT Protocol Samplers (XMeter)

mqtt-xmeter

2.0.2

Connect, publish, subscribe and disconnect samplers for MQTT.

Low activity: repository last updated 2023-05; the jar bundles its dependencies. The mqtt-sampler entry (0.0.1-SNAPSHOT) is not maintained.

JMeter gRPC Request

jmeter-grpc-request

2.0.2

gRPC sampler that parses .proto files at runtime; blocking unary calls only.

Continuation: the original zalopay-oss repository was archived (last release 1.2.6, 2022-12); the catalogue now points to the bakthava fork, 2.0.0 to 2.0.2 released 2026-04 (CVE fixes, mTLS fields, Java 21 build fixes). Low adoption.

Two things this table does not change: core JMeter has no HTTP/2, WebSocket, Kafka, MQTT or gRPC support, so for those protocols a plugin is the only JMeter option; and the presence of an entry in the catalogue says nothing about its quality. The HTTP/2 sampler is introduced on HTTP Requests, and the core JSON extractors that replace jpgc-json on Correlation & Extractors.

Source: JMeter Plugins repository catalogue, BlazeMeter HTTP Plugin README, jmeter-grpc-request (bakthava), jmeter-grpc-request (zalopay-oss, archived), Custom JMeter Functions (JMeter Plugins wiki)

How to judge a plugin before using it

A plugin becomes part of every measurement it touches. Before building a test on one, check:

Check How to check it

Last release and activity

The newest version in the catalogue, its date on Maven Central or GitHub, and whether issues get answers. Years without a release are acceptable for a simple, finished plugin (Dummy Sampler) and a risk for one that wraps a fast-moving client library (Kafka, gRPC, HTTP/3).

Maintainer and archive status

Who publishes it, and whether the repository is archived or has moved. jmeter-grpc-request is the example: the catalogue id stayed the same while the maintainer changed.

JMeter and Java compatibility

The catalogue’s changes text ("Requires JMeter 3.2+"), the depends list (jmeter-core, jmeter-http) and the README (bzm-http2 needs Java 17). Test on the exact JMeter version you run before upgrading either side.

Licence

A LICENSE file in the source repository, or the licence in the POM. A missing licence is a legal question for your organisation, not a technical one.

Dependencies

The libs of the catalogue entry, or the POM. Libraries that JMeter also bundles (json-path, Jackson, Groovy, Log4j) can conflict; old copies can carry known vulnerabilities, as the CVE list in the jmeter-grpc-request 2.0.0 notes shows.

Where the jar comes from

Maven Central, a GitHub release, or jmeter-plugins.org/files. Prefer sources with checksums, and pin the version.

SNAPSHOT versions

An entry offering only a -SNAPSHOT version is a development build. Do not base a test on it.

A core alternative

Core JMeter has absorbed several plugins over time (JSON extractors and assertions in 4.0, the Precise Throughput Timer in 4.0, the Open Model Thread Group in 5.5). A core element is supported by the Apache project; a plugin is not.

From the books to 5.6 to 6.0

Era How plugins were installed and used

JMeter 2.11 to 3.0 (the books)

JMeter Cookbook (appendix) installs plugins by unzipping the "Standard" and "Extras" sets into the JMeter directory; chapter 6 uses the Ultimate and Stepping Thread Groups and the Throughput Shaping Timer, and chapter 2 the JSON Path Extractor plugin. Performance Testing with JMeter (chapter 5) and Pro Apache JMeter (chapter 9) monitor servers with PerfMon and ServerAgent. Plugin elements were prefixed jp@gc in the menus.

JMeter 3.x to 5.5

The Plugins Manager replaces the zip sets; plugins are installed one by one with dependencies resolved. JMeter 4.0 moves JSON extraction and assertion into core, which deprecates jpgc-json. The Concurrency and Arrivals thread groups supersede the Stepping Thread Group; JMeter 5.5 adds the core Open Model Thread Group.

JMeter 5.6 to 5.6.3

Plugins are found through ServiceLoader as well as by scanning lib/ext (PR 5885), so start-up is faster and old plugins keep working. Plugins Manager 2.0 (2026) speeds up catalogue loading and needs cmdrunner 2.3.

JMeter 6.0 (planned)

Per xdocs/changes.xml on the apache/jmeter master branch: Java 17 or later is required; the MongoDB elements are removed (the catalogue’s jmeter-mongodb entry becomes meaningless); several bundled libraries are upgraded (Groovy 5.1.3, json-path 3.0.0, Apache Tika 4.x, Saxon-HE 13, Kotlin 1.9 or later). A plugin compiled against the older versions of those libraries, or one that ships its own copy, may break; re-test every plugin when 6.0 is released. Nothing in the planned changes alters the lib/ext model or the Plugins Manager.

Source: Changes History, changes.xml on master (apache/jmeter)

Pitfalls

  • Treating jmeter-plugins.org as part of Apache JMeter. It is a separate community project; Apache does not support its plugins, and bugs in them are reported to their own maintainers.

  • Unpinned installs. install id and install-for-jmx take the newest version on the day the image is built, so two builds of the "same" generator can differ. Pin with id=version.

  • Different plugins on different nodes. A distributed test where one node lacks a plugin fails on that node; one with a different version produces results that cannot be compared.

  • Jars in the wrong directory. Libraries in lib/ext slow start-up; plugins in lib are never found; two versions of a jar on the classpath behave unpredictably.

  • Following the wiki’s cmdrunner-2.0.jar. The command-line script generated by Plugins Manager 2.0 runs cmdrunner-2.3.jar; with only 2.0 present it fails to start.

  • No write access. A JMeter installed by root and run as another user cannot be changed by the Plugins Manager.

  • Stale cache. Plugins missing from the dialog after a catalogue update: delete pmgr_cache in java.io.tmpdir.

  • GUI graph listeners left in a load run. They hold results in memory; remove or disable them for CLI runs.

  • Transitive Maven dependencies. <downloadExtensionDependencies> left at true copies old ApacheJMeter_core jars into the build’s JMeter; switch it off and list the libraries explicitly.

  • Deprecated plugins kept out of habit. jpgc-json and PerfMon still install, but core elements and server-side monitoring do the job with support from the Apache project or from your monitoring stack.

References