Passing the location of the Maven settings.xml file to Maven Publish

There is an excellent solution at How can gradle use repository settings from maven’s settings.xml to publish artifacts to a repository?

I work for a DevOps group in a major bank. We have an appdev team that has moved to Gradle as their build mechanism and have a requirement to upload to Nexus.

From the information I have been able to find, the plugins for ‘maven-publish’, and ‘maven-publish-auth’ uses the either the USER or GLOBAL location for the settings.xml.

As an enterprise devops team, our build tools support multiple version of maven, so we have multiple locations of a settings.xml. Whether Maven v2 or v3.

I see the System.getProperty(someProperty), but that doesn’t appear to be an approach that allows use to identify the location, or have build.gradle code to use to get a specific folder on a build server for the settings.xml.

Are there suggestions or recommendations on an approach that supports a dynamic mechanism that a build.gradle script will use to locate a settings.xml other than the USER or GLOBAL locations?

You may want to try the Maven Settings Plugin. The location to the settings.xml file can be configured via an extension property.

mavenSettings {
    userSettingsFileName = "path/to/settings.xml"

Thanks Mark… this would need to support a param of some sort so we don’t a fixed or hard-coded value… if this plugin is used within a build.gradle script, I assume this support a cmd line arg?

You could very easily use a project property to set the value and pass it via the command line.

mavenSettings {
    userSettingsFileName ='maven.settings.location')

Then when executing your build:

./gradlew -Pmaven.settings.location=path/to/settings.xml build
1 Like

Thank you for the quick response. We will give this a try… resulting post or follow-up questions to follow shortly…


We have tried to resolve this following existing documentation, and mechanisms. We have not pushed your Maven Settings Plugin into our internal repo, but that may be our next step.

We are now getting the Return code is: 401 which we know is authorization related.

We are passing a command line of
[gradlew -i -Dmaven.settings=D:\location\maven.home\conf\settings.xml installDevops]

I know it is finding the settings.xml, because when I remove it or rename it, we get,~ “can’t locate settings.xml”.

We have this configured correctly from everything I have compared it to. Here is an example of our build.gradle and config:

 apply plugin: 'groovy'
 apply plugin: 'idea'

 buildscript {
     repositories {
         maven {
             url ""
     dependencies {
         classpath ''

 dependencies {
     compile gradleApi()
     compile localGroovy()

 apply plugin: 'maven-publish'
 apply plugin: 'maven-publish-auth'

 ext {
     groupId = ''
     versionId = '1.0-SNAPSHOT'
     artifactId = 'appname'

 def groupId = group = ''
 version = '1.0-SNAPSHOT'

 publishing {
     publications {
         mavenJava(MavenPublication) {
             groupId = project.ext.groupId
             artifactId = project.ext.artifactId
             version = project.ext.versionId

     repositories {
         maven {
             name "central"
             url ""

task installDevops(dependsOn: 'publish') {


Based on this article:

On line 67, it should pickup the maven.settings arg off the command line.

We are using Maven 3.1.0, I tried backing it down to version Maven 2.2.1. No luck.

We know the credentials stored in our Maven settings.xml are valid and the repository urls are correct.

Any other ideas?

Everything looks ok in your build script. That plugin has been inactive for awhile so I’m not sure you’ll get much traction contacting the build author. You may have to debug to the plugin to see exactly what’s going on.

Also, is it strictly necessary that the credentials for publishing be stored in a settings.xml file? Is this being done for backwards compatibility with Maven? If not, the recommended approach is to externalize credentials in a file.

Hi Mark… yes, we are an enterprise team, and have a standard in place to access the Nexus credentials from the settings.xml file in a consistent way, regardless of the build mechanism. We support the usual, Ant, Maven, MSBuild, Gradle, and PowerBuilder build types. We also support multiple versions of Maven, so the path to the settings.xml, if used, can vary for build types. We have been able to accomplish what was needed keeping the settings.xml available on the build servers themselves, without propagating the file/credentials out to individual app teams. So, are we saying that your Maven Settings Plugin will support the cmd line approach, passing in a location other than the GLOBAL or USER default locations?

Yes, see the example above.

Mark… how would we get a compiled version of your plugin? And who do you work for?



You can download the plugin from the plugin portal. I work as a core developer for Gradle Inc.

it is working for me