testrunner VM initialization error solution

I recently started seeing VM initialization errors while calling out to testrunner.bat from my test driver. A web search revealed a SoapUI Pro forum topic which described a workaround involving edits to the -xmx value in testrunner.bat. That solved the immediate problem, but wasn't suitable for my situation - my tests are shared, and I don't want to force users to tweak their local configs (not to mention that "edit our source code to fix it" is essentially a cop-out.)

So, with that in mind, I made a few tweaks to testrunner.bat to make this all work the way I want it to, and I thought I'd share them here in case others face this same problem. Some of the changes are necessitated by the fact that I'm now maintaining a customized copy of testrunner rather than running the installed version.

relevant edits to testrunner.bat:

set SOAPUI_HOME=%~dp2
...
set JAVA_OPTS=-Xms128m -Xmx%1m -Dsoapui.properties=soapui.properties "-Dsoapui.home=%SOAPUI_HOME%\"
...
SHIFT
SHIFT
"%JAVA%" %JAVA_OPTS% com.eviware.soapui.tools.SoapUITestCaseRunner %~1 %~2 %~3 %~4 %~5 %~6 %~7 %~8


Having done this, I can now call testrunner.bat from my test driver with 2 extra (required) args:
1) a new/reduced -xmx value to prevent VM initialization errors (I'm using 512; 50% less than the default 1024, and it seems to be working fine)
2) SOAPUI_HOME, because I'm not calling the installed version of this file anymore, so I can't rely on it's location to be SOAPUI_HOME

So, my call now looks something like this:

'cmd /C {CurrentPath}\testrunner 512 "C:\Program Files (x86)\eviware\soapUI-3.6.1\bin\" -a -f{CurrentPath} ...'

And by distributing the customized testrunner with my test code, I've eliminated the need for all users to manually implement the solution.