I like the Engine launcher in the archetype but it seems to be
incompatible with the normal gatling.sh. The former likes to have
normal Scala class file names, e.g. CreateUsersSimulation.scala, while
the latter enforces a naming convention like myapp@CreateUsers.scala.
That means I can't share my simulations with a colleague who prefers
to use gatling.sh. Am I missing something? Can I configure one or
the other to look in the same files for simulations?
Hi Dave,
I must admit that I didn’t think of this use case when we designed the conventions.
In the shell mode, having a fine named xxx@yyyy.scala means that the content of the yyyy directory will be collected, compiled and loaded in the same ClassLoader. This was intended to provide a way to modularize and reuse scenario parts.
The Engine can later as a way of coding scenarios with IDE goodness: compile checks, auto-completion.
I realize now that we didn’t think of a way to make these two modes compatibles.
Let me think about it.
Cheers,
Stéphane
2012/2/9 Dave Syer <david.syer@googlemail.com>
I must admit that I didn't think of this use case when we designed the
conventions.
Actually the Engine launcher doesn't work at all with 1.1.0-SNAPSHOT.
I'm still using the 1.0.3 archetype, so maybe that's the problem (I
had to hack it a bit). It fails to detect scenario .scala files in
the package provided. Maybe I got the Gatling.apply() params wrong
(the signature seems to have changed)?
object Engine extends App {
Gatling(dataFolder, resultsFolder, requestBodiesFolder,
eclipseAssetsFolder, eclipseSimulationFolder)
}
Hi Dave,
Yes, only the 1.1.0-SNAPSHOT archetype is compatible with 1.1.0-SNAPSHOT core, as parameters where renamed.
But you found it out by yourself and was able to tweak the Recorder, so you should be fine.
And damn, you’re right, the cooperation between the Recorder and the Engine is broken in the archetype.
I’m going to fix this ASAP and then find out how to fix the archetype/standalone compatibility problem.
I’ll let you know.
Thanks,
Stéphane
2012/2/10 Dave Syer <david.syer@googlemail.com>
Actually, I messed up my previous test and the archetype works fine for me.
Could you try the 1.1.0-SNAPSHOT archetype, please?
https://github.com/excilys/gatling-highcharts
It works. Actually I just copied the code from github into my
project, but that worked with my old simulations.
Good news do happen! 
2012/2/10 Dave Syer <david.syer@googlemail.com>
Hi,
I thought of a new organization for files.
What exists now:
simulations/
-advanced-script-example/
-scn_scenario.scala
-otherScn_scenario.scala
-advanced-script-example@default.scala
What I suggest:
simulations/
-advanced_script_example/
-default.scala
-components/ ← We may choose a good name here (components is fine for me ^^)
-scn_scenario.scala
-otherScn_scenario.scala
And in the maven projects:
my.package.simulations.advanced_script_example
my.package.simulations.advanced_script_example.Simulation (in a file named default.scala, scala has no problem with that)
my.package.simulations.advanced_script_example.components…
You know what I mean.
What I basically say is that the simulation group should now be a folder and the simulations should be files.
Instead of mygroup@myconf.scala we could have mygroup/myconf.scala which could be interpreted by both the bundle and the archetype engine.
I know it’s not perfect yet, but we can look in this way I think.
Cheers,
BluePyth
What I suggest:
simulations/
>-advanced_script_example/
>-default.scala
>-components/ <-- We may choose a good name here
(components is fine for me ^^)
>-scn_scenario.scala
>-otherScn_scenario.scala
That looks fine to me (as long as it works with both gatling.sh and
Engine.scala).
I actually would prefer to be able to specify the locations more
dynamically - naming conventions and package scanning are fine, but it
would be nicer if there was also a way to control which simulations
that are launched from Scala. Since a simulation is just an instance
of GatlingSimulation I ought to be able to import/inject one just by
instantiating it, e.g.
val sim1 = new FirstSimulation()
val sim2 = new SecondSimulation()
sim1.runSimulation(
user.configure users 10 protocolConfig httpConf)
sim2.runSimulation(
user.configure users 20 ramp 2 protocolConfig httpConf)
Or is there a way to do that already that I missed?
@Dave : Why do you want to import Simulations? Isn’t being able to import Scenarios sufficient?
Currently,you’re not supposed to launch 2 simulations at the same time, that would mess up with the engine being launched twice.
@Romain I realize that the app API was first intended for launching txt scripts and shifted along the way to being scala compatible without much thought about it because we were focused on the DSL.
For example, why does GatlingSimulation extend App?
We have to clean this up for 1.1.
2012/2/10 Dave Syer <david.syer@googlemail.com>
How do you do that in Scala (I only see .txt examples on the wiki -
maybe I'm missing something)? I can't see an include() method
anywhere.
The include is simply a hack because you can’t do imports in txt.
In Scala, you simply do imports.
I’m going to push a scala sample on master, give me 5 secs.
2012/2/10 Dave Syer <david.syer@googlemail.com>
Here it is :
https://github.com/excilys/gatling/commit/cfc2787ec57ed220558c2056fe78e62ff60c38d7
2012/2/10 Stéphane Landelle <slandelle@excilys.com>
Hi,
I have another proposal, lets forget about conventions, and use a deep scan the simulation directory.
simulations/
aaa/bbb/ccc ← value generated by the recorder = timestamp, deep discovery until a .(txt|scala) file is found
foo.(txt|scala) ← value generated by the recorder = Simulation.(txt|scala)
ddd/eee/fff
bar.(txt|scala) ← pick up only files with the same extension as foo
In scala mode, we expect people not to mess with the package declarations and the imports.
WDYT?
I'm not sure I understand really (and particularly the comment about
messing with stuff). You mean you would scan subdirectories are
compile everything with the same file extension? I like that if it
allows me to modularize my simulations - I can define common chains in
a utility class and re-use it in multiple scenarios? I like it if it
allows me to use sensible file names for all scala code.
A scala import only works if the imported file is on the classpath.
It wouldn't be if you were running from gatling.sh would it?
2012/2/15 Dave Syer <david.syer@googlemail.com>
I’m not sure I understand really (and particularly the comment about
messing with stuff). You mean you would scan subdirectories are
compile everything with the same file extension?
Yes
I like that if it allows me to modularize my simulations - I can define common chains in
a utility class and re-use it in multiple scenarios?
Exactly, for example, you can put your parts into an object, and import them into your simulation.
As you have real Scala files, you just have to properly declare the imports.
I like it if it allows me to use sensible file names for all scala code.
Exactly. We drop the naming conventions, so the “proper” way is having the same file name as the class/object.
Yes, it would, as we collect all the files (the selected simulation file AND the parts in sub directories) and compile and load them altogether.
2012/2/15 Dave Syer <david.syer@googlemail.com>
Stephane,
Is there a github issue for these features so we can track the
progress? I scanned the list and didn't see anything obvious, but I
might have missed something? You want me to open one?
Dave.
Hi Dave,
No, I’ve not opened an issue yet, because I haven’t found a solution I’m really satisfied with.
All those questions are forcing me to reconsider quite a few things. I’m experimenting in a branch (https://github.com/excilys/gatling/tree/AppRefactoring).
I’ve just sent another message on the Google Group regarding dropping the txt format.
I’ll definitively come up with a clean solution by the end of next week.
Stéphane
2012/2/16 Dave Syer <david.syer@googlemail.com>