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?
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?
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:
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 gradle.properties 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?