Artifactory resolution repo config still split between Jenkins and Gradle

[Cervator]

After upgrading to latest Jenkins (1.643), Artifactory (4.3.3), Gradle (2.10), and Artifactory plugin for Jenkins (2.4.6) + Gradle (4.0.0) the resolution repo settings still come from two different places as evident at http://jenkinsupgrade.terasology.org:8080/job/NanoMultiBlock/3/console

Which will eventually go poof as it is a test server so here's a snippet:

We're in a single-project non-Core module workspace (Jenkins) so will look elsewhere for dependencies
*** Attempting to fetch dependency module from Artifactory for MultiBlock: Core
Download http://artifactoryupgrade.terasology.org:8081/artifactory/virtual-repo-live/org/terasology/engine/engine/0.54.6-SNAPSHOT/engine-0.54.6-20151230.042148-15.pom
Download http://artifactoryupgrade.terasology.org:8081/artifactory/virtual-repo-live/org/terasology/engine/engine-tests/0.54.6-SNAPSHOT/engine-tests-0.54.6-20151230.042148-15.pom
Download http://artifactoryupgrade.terasology.org:8081/artifactory/virtual-repo-live/org/terasology/modules/Core/0.54.6-SNAPSHOT/Core-0.54.6-20151230.042148-15.pom
*** MultiBlock remotely resolved org.terasology.engine - engine - version 0.54.6-SNAPSHOT
*** MultiBlock remotely resolved org.terasology.engine - engine-tests - version 0.54.6-SNAPSHOT
*** MultiBlock remotely resolved org.terasology.modules - Core - version 0.54.6-SNAPSHOT
*** MultiBlock remotely resolved org.terasology - gestalt-module - version 5.0.1
*** MultiBlock remotely resolved org.terasology - gestalt-asset-core - version 5.0.1
*** MultiBlock remotely resolved org.terasology - TeraMath - version 1.1.3
*** MultiBlock remotely resolved org.terasology.bullet - tera-bullet - version 1.0.3
*** MultiBlock remotely resolved org.terasology - splash-screen - version 1.0.2
*** MultiBlock remotely resolved org.terasology - CrashReporter - version 2.1.0
*** MultiBlock remotely resolved org.terasology - gestalt-util - version 5.0.1
:clean UP-TO-DATE
:compileJava
Download http://artifactoryupgrade.terasology.org/artifactory/virtual-nanoware-and-remote/org/terasology/engine/engine/0.54.6-SNAPSHOT/engine-0.54.6-20151231.024817-2.pom
Download http://artifactoryupgrade.terasology.org/artifactory/virtual-nanoware-and-remote/org/terasology/engine/engine-tests/0.54.6-SNAPSHOT/engine-tests-0.54.6-20151231.024817-2.pom
Download http://artifactoryupgrade.terasology.org/artifactory/virtual-nanoware-and-remote/org/terasology/modules/Core/0.54.6-SNAPSHOT/Core-0.54.6-20151231.024817-2.pom
Download http://artifactoryupgrade.terasology.org:8081/artifactory/virtual-repo-live/org/terasology/engine/engine/0.54.6-SNAPSHOT/engine-0.54.6-20151230.042148-15.jar
Download http://artifactoryupgrade.terasology.org:8081/artifactory/virtual-repo-live/org/terasology/engine/engine-tests/0.54.6-SNAPSHOT/engine-tests-0.54.6-20151230.042148-15.jar
Download http://artifactoryupgrade.terasology.org:8081/artifactory/virtual-repo-live/org/terasology/modules/Core/0.54.6-SNAPSHOT/Core-0.54.6-20151230.042148-15.jar
:processResources UP-TO-DATE
:classes

It appears that the override settings in Jenkins only overrides part of the resolution requests, in this case resulting in actually getting files split between the default virtual-repo-live (defined in Gradle) and the overridden virtual-nanoware-and-remo (defined in Jenkins)

This is not a problem for live stuff but is rather quirky if trying to do any testing that relies on resolving specific artifacts. It may be doable to catch the settings from Jenkins in Gradle and force the use of the right values in artifactory.gradle.