I’m in process of investigating what it would take to migrate our projects from Gatling 2.0 to 2.1.
The project is built with Gradle, and Gatling is run by a custom Gradle task as a Java application. The gatling.conf file contains a custom directory path.
When I upgrade version to 2.1, the gradle build succeeds (no error codes), but Gatling fails to start.
Instead, I get a message with text like “cannot find Simulation file”. There is also text indicating that Gatling expects to find the Simulation in “user-files” directory. This sounds like the location that Gatling uses for local installations. Our project is not using a local install of Gatling; it normally pulls these dependecies in
How can I get Gatling to recognize my custom path again?
The only change I have made in my code was to update Gatling version number.
You use an unsupported Gradle set up. No idea what you’re doing here.
Hi Stephane:
I realize you do not officially support Gradle and respect your choice to not change despite many requests to the contrary. However this is a bit perplexing, because despite being ‘unsupported’, my project used to work with Gatling 2.0 and with all the RCs before it, so I’m hoping you can throw me a bone.
After upgrading to Gatling 2.1 in same project, I’m getting a message that indicates Gatling expects my script to be in the default location instead of the custom location specified in gatling.conf file.
I’m trying to get more information about design decisions made in Gatling 2.1 so I can implement a workaround for this. I suspect it’s related to how Gatling is compiled, but my understanding of this is rather limited. I could use more clarification.
My project’s setup was described in a previous post. Details here>
https://groups.google.com/forum/#!searchin/gatling/gradle/gatling/9-SHZ5OmIMI/XBNi4vs2HFkJ
Hi Nadine,
About Gatling non-support of Gradle : please remember that, currently, Gatling is mostly maintained by two people: Stéphane and me.
This means the manpower available and time to develop Gatling further is very limited, and therefore we need to set priorities.
Official Gradle support (there are third party plugins) isn’t one.
About your issue:
Since Gatling 2.1, Gatling does not compile the simulations itself.
The compilation is handled by a separate process, called ZincCompiler. It used to be called by Gatling at startup, but that leads to many issues, the main one being that the Scala version Gatling could use was locked to the one the compiler is using.
This was what allowed us to upgrade to Scala 2.11.
Therefore, Gatling can’t find your simulations because they were not compiled.
Please note that this change is mentioned in the migration guide, which is always a nice read when you upgrade Gatling 
This basically means that you’ll need to handle the simulations compilation yourself, either by calling ZincCompiler in the same way that the scripts or the Maven Plugin does, or by using Gradle Scala Plugin (way simpler).
Cheers,
Pierre
Hi Nadine,
As Pierre explained, we're currently 2 core committers here, so we have
limited resources and have to pick our priorities properly.
We don't have any problem with supporting Gradle, just that we have more
pressing matters to deal with.
Supporting Gradle officially would require:
- us to grow some Gradle skills
- develop the plugin
- maintain it, to be both compatible with Gatling changes AND Gradle
changes (just like we're about to release a fix for our maven plugin that
stopped working with maven 3.3)
The other possibility would be that some community member would be willing
to tackle this and commit on maintaining it on the long term.
Sadly, it's usually easier to come up with some quick solution that matches
one's specific needs than develop something clean and generic and support
it for years.
Official modules have to fall into the second category.
You have several possibilities:
- use a third party: https://github.com/alphagov/gradle-gatling-plugin.
It seems to be compatible with Gatling 2.1. But then, we, core committers,
don't guarantee anything in there.
- develop your own, but then, yes, you'll have to cope with Gatling's
breaking internal changes
- have your company contract with us so we can turn down other contracts
and work on bringing official Gradle support
Regards,
*Stéphane Landelle*
*Lead developer*
slandelle@gatling.io
Hi Nadine,
Is there no possibility of switching to SBT? There is an example project here:
https://github.com/gatling/gatling-sbt
Aidy
Thanks for the info about ZincCompiler. I’ve seen some references to that in the output from our tool, but there were also references to scalac so I wasn’t sure exactly how it all worked together. This will help.
BTW, I did not mean to denigrate the work you do with Gatling. It’s an amazing product, and it has served us well in our projects.
@stephane Thanks for the info on plugins and on the other options. The decision to use gradle was not mine; it is a company/project standard, so I’m trying to work within those constraints. Having this information will help me decide on best course of action.
Thanks for the link. I will look into it to become more informed.
For me, learning SBT has been pretty low priority (because I’m in a similar situation to what Stephane and Pierre face with Gradle and Gatling).
However, there are more projects coming into our ecosystem that use Scala, so perhaps we’ll gain enough momentum to bring in SBT as part of the standard toolset.