gatling maven plugin does not override the default values

I am using the maven plugin for 2.0.0. And tried to overide the default values like -Dgatling.noReports=true. I change the value to true either from commandline -D or from the pom.xml properties. Seems like it still use the default, in my case, even I set the noReports = true, it still generate the report. I also tried other properties like the dataFolder. Seems like none of them can be overriden. Can you help to see what is going on?

Thx
Shawna

I’ve just tried the snaphot on Sonatype, and -Dgatling.noReports=false does generate the reports while -Dgatling.noReports=true doesn’t.

Here’s my sample. Does it work for you?

gatling-maven-plugin-demo.zip (110 KB)

I am using this version:

<gatling.version>2.0.0-M3a</gatling.version>

And in the command -Dgatling.noReports=true

This is the result:
“Reports generated in 0s.
Please open the following file : /Users/shawna.qian/jive_code/performance/gatling-maven/target/gatling/results/standardtest-impactstats-query-20131213082018/index.html”

In you sample is using snapshot version which I can’t use in the company for some policy.

Will that make difference?

Thx

Here’s a project with Gatling 2M3a.

On my machine, mvn gatling:execute -Dgatling.noReports=true properly skips reports generation.

gatling-maven-plugin-demo.zip (112 KB)

Thx for the example. The RE from my company updated some settings on nexus to mirror the right version of the plugin. Seems like the override properties works now. at least -Dgatling.noReports=true and -Dgatling.resultsFolder works too (Those are the 2 that I was trying). But I still can’t get -Dgatling.dataFolder working. No matter where I put the value, it always goes to src/test/resources/data to find the feeds. Can you double check it?

Thx a lot!

gatling.dataFolder doesn’t seem to be working with 2M3a but I checked and it works with the snapshot…

I can assert that Maven does pick up the value form command line. Because if I do:

mvn -X test -Dgatling.dataFolder=whatever

And inspect the arguments (the -df) pass to the forked JVM it’s actually the value I specified. Does Gatling.scala properly picks up the -df argument?

No. Gatling app can only pick up props whose name matches the one in gatling.conf.

So yea after some digging there is a bug in M3a release.

The M3a release will always find the file for feeder in a directory name called “data” in any of the class path that’s why if you invoke Gatling through maven it will always find data in src/test/resources/data.

Here is what happened:

When Maven runs it will copy src/test/resource/* to target/test-classes. Then target/test-classes will be part of the classpath. So when Gatling runs it will always find resource under target/test-classes/data. The dataFolder argument is actually
never considered.

To work around it you will have to put the feed files under /data/ and add to the classpath before target/test-classes.

Yea it’s very confusing and it’s only broken in M3a; SNAPSHOT version actually fixes it.

If you are keen you can actually take a look at: https://github.com/excilys/gatling/blob/2.0.0-M3a/gatling-core/src/main/scala/io/gatling/core/config/GatlingFiles.scala

These lines:


         def validateResource(filePath: Path, defaultFolder: String): Validation[Resource] = {
                val defaultPath = defaultFolder / filePath
                val classPathResource = Option(getClass.getClassLoader.getResource(defaultPath.toString.replace('\\', '/'))).map { url =>
                        url.getProtocol match {
                                case "file" => FileResource(url.getFile.toFile)
                                case "jar" => ClassPathResource(url, filePath.extension)
                                case _ => throw new UnsupportedOperationException
                        }
                }

                val resource = classPathResource.orElse(filePath.ifFile(path => FileResource(path.toFile)))
                resource.map(_.success).getOrElse(s"file $filePath doesn't exist".failure)
        }

        def feederResource(filePath: Path) = feederFileMemo.getOrElseUpdate(filePath, validateResource(filePath, "data"))

are actually the culprit.