Also, there is typo in 1.378 changelog, JENKINS-4963 issue is being referred to instead of JENKINS-4693.

Hudson doesn't work as described behavior and this is still not fixed. When configuring build alternate settings.xml file validation fails in all cases except in case when alternate settings.xml file path is given relative to workspace root. If configured so plugins like sonar fail to access alternate settings.xml file since they are being run from (first) module root (notice "[trunk]" in sonar execution log snippet above).

Also I noticed that the maven2 jobs are checking poms before running any maven goals.

I have some jobs configured with the "-s" option in the "goals & options" field and they fail because the wrong settings file is used. Alternative settings.xml is noticed from this field and as there's nothing specified in the appropriate field, the one in ".m2" or the global one is taken instead.

I'll reconfigure my jobs but I think this should be considered as the path to the settings file is sometimes not very related to the job itself.
I noticed that after upgrading from 1.36x to 1.379. I think the 1.378 and #4963 has something to do.

Hudson sonar plugin seems to get relative path to alternate settings.xml, relative from workspace root (so as configured for the build job), but sonar plugin is running from module root. This doesn't seem to be the case with hudson maven plugin which prints out absolute path to alternate settings.xml as being used so it's not a problem that maven is run from module root. Not sure if (sonar) plugin needs to be adjusted because of changes to plugin API behavior or it's a bug in plugin API changes because they broke backward compatibility for passing configured alternate settings.xml path to the plugins.

[1] maven plugin execution

[trunk] $ /usr/lib64/jvm/java/bin/java -cp /var/lib/hudson/maven3-agent.jar:/var/lib/hudson/tools/Apache_Maven_3.0/boot/plexus-classworlds-2.2.3.jar org.jvnet.hudson.maven3.agent.Maven3Main /var/lib/hudson/tools/Apache_Maven_3.0 /var/lib/hudson/slave.jar /var/lib/hudson/maven3-interceptor.jar 37943
<===[HUDSON REMOTING CAPACITY]===>���channel started
Executing Maven: -B -f /var/lib/hudson/workspace/BuildJob/trunk/pom.xml -s /var/lib/hudson/workspace/BuildJob/trunk/settings.xml verify deploy

[2] sonar plugin execution

[trunk] $ /var/lib/hudson/tools/Apache_Maven_3.0/bin/mvn -f "/var/lib/hudson/workspace/BuildJob/trunk/pom.xml" -s trunk/settings.xml -e -B sonar:sonar -Dsonar.jdbc.driver=com.mysql.jdbc.Driver -Dsonar.jdbc.url=jdbc:mysql://sonar.foo.bar:3306/sonar?useUnicode=true&characterEncoding=utf8 ******** ******** -Dsonar.host.url=http://sonar.foo.bar:9000

Couldn't jenkins just pass to plugins absolute path to configured alternate settings.xml file, so it doesn't matter from where (from which working directory) plugin (like sonar) runs from?