Not able to set resultsFileFormat to CSV at execution level

Hi all,

I’m updating my jmeter-maven-plugin from version 1.10.1 to 2.5.1 (the latest at the moment). Everything is fine except that now the same configurations, which allowed me to output the results in CSV, now output the results in JTL.

I’m running the Maven (version 3.3.3) command in a Java 8 (version 1.8.0_151) Windows environment and this is my plugin configuration (which was working with the 1.10.1 version)

<plugin>
	<groupId>com.lazerycode.jmeter</groupId>
	<artifactId>jmeter-maven-plugin</artifactId>
	<version>2.5.1</version>
	<executions>
		<execution>
			<id>jmeter-tests</id>
			<phase>verify</phase>
			<goals>
				<goal>jmeter</goal>
			</goals>
			<configuration>
				<testFilesDirectory>src/test/resources</testFilesDirectory>
				<propertiesFilesDirectory>src/test/resources</propertiesFilesDirectory>
				<ignoreResultFailures>true</ignoreResultFailures>
				<resultsFileFormat>csv</resultsFileFormat>
			</configuration>
		</execution>
	</executions>
</plugin>

This is the command I’m running

mvn verify

[gvdm90]

Hi @Ardesco,

thanks a lot for the support and the detailed explanations. I tested the new configuration structure and it worked (no surprises) 😃 When a change is done for a better adherence to the standards it is always good. We will proceed with the new changes in the configurations and upgrade to the latest version.

Thank you again Regards Giulio

[Ardesco]

In version 1.x of the plugin we used to construct the JMeter directory structure, download dependencies, run tests and check results in the integration-test phase. This is why you could chuck all the configuration in the execution block, because it was effectively the same as placing it outside the execution block.

For 2.x we tried to move to a more standard set of maven phases:

http://books.sonatype.com/mvnref-book/reference/lifecycle.html

Why did we do it? Well the plugin has 3 distinct roles, the first one is constructing your JMeter directory structure. The second is actually running your tests and the third is performing some verification on tests.

If we break these down into separate phases we can start to ignore some phases, this becomes useful when you have a series of sub-modules and you want to place the plugin configuration in the parent module, but you want to disable running of some phases in the sub modules.

Having verify in its own separate phase also means that you don’t have to perform result check as part of the build, you can run a build and then later on decide to run the verify phase using the already stored results.