A regression has been introduced in this commit:
When there are spaces in the job name, and thus the workspace path (and its associated temporary dir), the generated $MAVEN_CONFIG variable is no more always a valid list of mvn command line options. The Maven global and user settings files are in the job's tmp dir, and thus can have spaces in their path, leading to something like this for a job named "build Something":
Also I've not tried, I assume that using a job specific Maven local repo could trigger a similar issue (through the -Dmaven.repo.local=... argument).
This used to work fine in 3.0.2, because ArgumentListBuilder was doing the right thing (quoting in toString()) to generate the complete command line. Fixing this in 3.0.3 is not obvious at first glance; the whole idea of using a string environment variable ($MAVEN_CONFIG) as a list of command line arguments is wrong when you don't have enough guarantee about what these arguments look like.
I understand the change was introduced to better support "mvnw" from Takari Maven wrapper. Maybe one option could be to not use this variable in the "withMaven Wrapper script"? (keep using an ArgumentListBuilder to generate your wrapper, and leave the broken $MAVEN_CONFIG thing to users of the mvnw script)
Or issue a warning message when you detect spaces in the workspace path?