Gatling 2.1.4 not seeing custom directory paths

[Nadine Whitfield]

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. 

[Stéphane LANDELLE]

You use an unsupported Gradle set up. No idea what you're doing here.

Stéphane Landelle

Lead developer

slan...@gatling.io

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nadine Whitfield]

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

---

Short story, I'm running Gatling by using java  command line instead of using the shell script. The project follows standard maven structure (src/test and src/main branches). 

The Gradle build script task creates the argument string like this>

task gatling (type: JavaExec)  {
    description = 'Runs LOAD test in Gatling'
    classpath = sourceSets.test.runtimeClasspath
    classpath += sourceSets.test.resources

    main = "io.gatling.app.Gatling"
    args = Eval.me("['-s', 'performance.simulations.LoadInjection']")
}

Custom directory paths are defined in gatling.conf. Since we're running Gatling on the fly (instead of local installation), the scripts and resources for Gatling are kept in same maven structured project as the application under test.  

### defines custom directory tree for Gatling
directory {
  data = ./src/test/resources/performance/data/
  requestBodies = ./src/test/resources/performance/request-bodies/ 
  simulations = ./src/test/scala/performance/simulations/
  results = build/reports/gatling/
}

Message from build tool>

The requested class('performance.simulations.Injector') can not be found in the classpath or does not extends Simulation.
There is no simulation script. Please check that your scripts are in user-files/simulations

[Pierre DAL-PRA]

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

[Stéphane LANDELLE]

On Sat, Mar 28, 2015 at 1:04 AM, Nadine Whitfield <nadine.w...@gmail.com> wrote:

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. 

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,

[empty account]

Hi Nadine, 

Is there no possibility of switching to SBT?  There is an example project here: 

https://github.com/gatling/gatling-sbt

Aidy

--

[empty account]

And now the correct link: https://github.com/gatling/gatling-sbt-plugin-demo

[nadine.w...@nike.com]

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. 

[nadine.w...@nike.com]

@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. 

[nadine.w...@nike.com]

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.