Gatling Plugin for Gradle
Groovy Scala Java
Clone or download
Ievgenii Shepeliuk
Ievgenii Shepeliuk readme
Latest commit b5a9f0b Apr 26, 2018


Gatling Plugin for Gradle


Follow the steps described at Gradle Plugin Portal page.

Java 8 Upgrade
  • Due to a bug Gatling 2.2.0 is supported only from gradle-gatling-plugin version 0.3.0

  • JDK 8 is required for Gatling 2.2.0, so this plugin is also require JDK8

For whatever reason you stuck with JDK 7, please keep using the 0.2.x series of this plugin.

Project Layout

Folders overview

The plugin uses src/gatling as its source root. There are several folders serving different purposes under the source root.

  • Simulation sources direcrory

  • Feeder data directory

  • Request bodies directory

  • Configuration directory

This plugin supports two project layouts.

  • Standard Gradle/Maven layout

  • Gatling-like layout

There’s no need to explicitly setup any of those. Plugin auto-detects layout during examination of project’s folder structure.

Standard Gradle/Maven layout

Directory Purpose


Simulation sources


Feeder data


Request bodies



Gatling-like layout

Directory Purpose


Simulation sources


Feeder data


Request bodies



Plugin configuration

The plugin defines the following extension properties in the gatling closure

Property name Type Default value Description




Gatling version




The default Gatling console log level if no logback.xml present in the configutation folder




scala version that fits your Gatling tool version



['-server', '-Xmx1G',
'-XX:+UseG1GC', '-XX:MaxGCPauseMillis=30',

Additional arguments passed to JVM when executing Gatling simulations


Closure or Iterable<String>

{ include "**/*Simulation.scala" }

Simulations filter.
If closure then See Gradle docs for details, otherwise an Iterable of simulations fully qualified names.

Custom source folder

If you have a special layout you can configure the source root folder and all gatling specific folders. Currently you have to set the source sets accordingly.


project.sourceSets {
    gatling {
        scala.srcDirs = ['src/test/gatling']
        resources.srcDirs = ['src/test/gatling/user-files/simulations', 'src/test/gatling/user-files/data', 'src/test/gatling/user-files/body', 'src/test/gatling/conf']

gatling {
    sourceRoot = 'src/test/gatling'
    simulationsDir = 'user-files/simulations' (1)
    dataDir = 'user-files/data' (2)
    bodiesDir = 'user-files/bodies' (3)
    confDir = 'conf' (4)
  1. the plugin looks for simulations in src/test/gatling/user-files/simulations

  2. data is located in src/test/gatling/user-files/data

  3. request bodies are be placed in src/test/gatling/user-files/bodies

  4. gatling configuration is located in src/test/gatling/conf


Overriding Gatling version and JVM arguments
gatling {
    toolVersion = '2.3.1'
    jvmArgs = [ '-server', '-Xms512M', '-Xmx512M' ]
Filtering simulations using FQN list
gatling {
    simulations = [ 'com.package1.MySimu', 'com.package2.advanced.MySimulation' ] (1)
  1. only execute com.package1.MySimu and com.package2.advanced.MySimulation simulations.

Filtering simulations using Groovy closure
gatling {
    simulations = {
        include "**/package1/*Simu.scala"    (1)
        include "**/package2/*Simulation.scala"  (2)
  1. all Scala files from plugin simulation dir subfolder package1 ending with Simu.

  2. all Scala files from plugin simulation dir subfolder package2 ending with Simulation.


Gatling uses logback to customize its output. To change logging behaviour, put your logback.xml into configuration folder, i.e. src/gatling/resources/conf or src/gatling/conf depending on choosen project layout.

If no custom logback.xml provided, by default plugin will implicitly use following configuration.

<?xml version="1.0" encoding="UTF-8"?>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
  <root level="${logLevel}"> (1)
    <appender-ref ref="CONSOLE"/>
  1. logLevel is configured via plugin extension, WARN by default.

Dependency Management

This plugin defines three configurations gatling, gatlingCompile and gatlingRuntime. By default plugin adds Gatling libraries to gatling configuration. Configurations gatlingCompile and gatlingRuntime extend gatling, i.e. all dependencies declared in gatling will be inherited.

Also project classes (src/main) and tests classes (src/test) are added to gatlingCompile and gatlingRuntime classpath, so you can reuse existing production and test code in your simulations.

Additional dependencies can be added by plugin’s users to any of configurations mentioned above.

dependencies {
    gatling '' (1)
    gatlingCompile 'org.apache.commons:commons-lang3:3.4' (2)
    gatlingRuntime 'cglib:cglib-nodep:3.2.0' (3)
  1. adding gson library, available both in compile and runtime classpath.

  2. adding commons-lang3 to compile classpath for simulations.

  3. adding cglib to runtime classpath for simulations.


Plugin provides dedicated task GatlingRunTask that is responsible for execute gatling simulations. Customer may create instances of this task to execue particular simulations. Task extends Gradle’s JavaExec task.

Default tasks

Additionally plugin creates several default tasks

Task name Type Description



Compiles Gatling simulation and copies resources



Executes all Gatling simulations configured by extension



Executes single Gatling simulation,
SimulationFQN should be replaced by fully qualified simulation class name.


Run all simulations
$ gradle gatlingRun
Run single simulation implemented in com.project.simu.MySimulation class
$ gradle gatlingRun-com.project.simu.MySimulation

Troubleshooting and known issues

Spring Boot and Netty version

Caused by io.spring.dependency-management plugin and Spring platform BOM files. The dependency management plugin ensures that all declared dependencies have exactly the same versions as declared in BOM. Since Spring Boot declares own Netty version (e.g. 4.1.22.Final) - this version is applied globally for all the configurations of the Gradle project, even if configuration doesn’t use Spring.

There’s 2 ways of solving the problem, depending on the actual usage of Netty in the project

  • When production code doesn’t rely on Netty

ext['netty.version'] = '4.0.51.Final'

This declares Netty version globally for all transitive dependencies in your project, including Spring.

  • When production code uses Netty

dependencyManagement {
    gatling {
        dependencies {
            dependencySet(group: 'io.netty', version: '4.0.51.Final') {
               entry 'netty-codec-http'
               entry 'netty-codec'
               entry 'netty-handler'
               entry 'netty-buffer'
               entry 'netty-transport'
               entry 'netty-common'
               entry 'netty-transport-native-epoll'

This options ensures that 4.0.51.Final will be used only for gatling configurations, leaving other dependencies unchanged.