Upgrade XSBT to 0.12.2 according to NPE issue

One of my Gtaling test is working locally, but I encoutered an NPE when I execute it under Linux with JDK 6


It’s indeed the same bug.

You can try to build a custom jar of Zinc after checking out the sources here : https://github.com/typesafehub/zinc/.

Also, I’m afraid that the next release of Gatling won’t contain the fix as there isn’t an official release yet.


I think that’s not a zinc snapshot that’s needed, but an sbt snapshot.
I’ll try to build one, check if everything still runs fine fine on my side and hand it over to you so you can test.


Something puzzles me!
You say that it fails under Linux, but your logs show “D:\busdata[subversion.michelin.com](http://subversion.michelin.com/)\xnetv3\xnt\trunk\05_impl\0_src\wrhWebPerf\user-files\simulations\wrh\WrhPerf.scala”

Did you upload on your Linux machine your whole local Windows directory?
If so, could you please empty the target directory? It contains a cache for the scala compiler and it might not be transportable.


I ran my tests locally on Windows and on my continuous integration server based on Jenkins under Linux ; on the first environment it was working and not on the second.
For sure, I tried to clean the target directory first to post my issue.

But I fixed it today:

  • I have download the last snaphot of ZINC (zinc-0.3.0-SNAPSHOT.tgz).

  • I have replaced some libraries: zinc-0.3.0-SNAPSHOT.jar + incremental-compiler-0.13.0.jar + compiler-interface-0.13.0-sources.jar

  • And it’s working fine on Linux

Good news for me, whereas It’s base on a snapshot !

Question is: How to integrate this fix in your next release if zinc release is not currently planned ?

Thanks for your help


So the problem is not related to the sbt issue you pointed as it’s stated to be fixed in upcoming sbt 0.12.2 while zinc master uses sbt 0.12.1.

I’m still puzzled about the Windows paths that appear in your log:


Do you have any idea?

I also quickly tested zinc 0.3.0-SNAPSHOT, and it seemed to run fine.
We could host and ship a timestamped zinc version. However, I’m a bit reluctant to do so as we plan on releasing Gatling 1.4.0 tomorrow. I don’t want to break anything without sufficient testing and end up regretting doing such a move.

As a consequence, I’d really like to understand what happens on your side and how zinc 0.3.0 did fix the problem. And I’d really also like to know where those Windows paths come from, as you’re running on Linux.


The path you caught is my local path, but it appears Jenkins/Linux side. I don’t know if it’s related to a build cache because I do not commit the target/ folder
I agree with you : it’s very strange and I’m not able to understand why zinc 0.3.0 fix my issue ; I understand it’s dangerous to release with a zinc nightly build

Thanks for your help.

Is this a blocker for you, or are you able to work with a workaround, such as hosting zinc snapshot on your own, and forcing version with dependencyManagement block?
Shipping a snapshot is something we’ve already done in the past. Here, the problem is actually about timing and getting sufficient time to test.


It’s not a blocker issue for me while I’m just in Proof of Concept mode :wink:
But I really like to integrate your tool in my customer development toolbox, and to do that, I should communicate I’ve no issue :wink:
To sum up, I’m able to work with this work-arround based on a zinc snapshot ; I’m not afraid to work with it but I really hope you will schedule an official fix.

Yep, we’ll fix this for 1.4.1, either with an official zinc release, or with a snaphot we’ll have fully tested.

As you seem to be working with Jenkins and maven, note that we’ll be releasing our own Jenkins plugin along with 1.4.0, and that the gatling-maven-plugin is getting some polishing.
So, you’d better stay tuned and read the migration guide :wink:



Thanks anew for your reactivity !