[GRADLE-2681] Mirror definition in maven settings.xml overwrites mavenDeployer configuration Created: 13/Feb/13  Updated: 25/Jan/15  Resolved: 25/Jan/15

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.4-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 3

Issue Links:
Duplicated by GRADLE-2877 Gradle upload caught by nexus mirror ... Resolved



I have a problem where gradle overrides my local mavenDeployer repository settings in build.gradle when I have a mirror defined in the maven settings.xml file. I've tried to remove the mirror settings and then it works without any problems. Is there a workaround for this that does not involve changing the settings.xml file?

This regards the uploadArchive task.

All input is appreciated.

Comment by Gradle Forums [ 13/Feb/13 ]

Perhaps related - Gradle appears to be loading the system maven configuration twice for me.

When running in debug mode, I see four settings files loaded.

1) gradle empty settings
2) M2_HOME/conf/settings.xml
3) USER_HOME/.m2/settings.xml
4) M2_HOME/conf/settings.xml

I replaced the system settings.xml with my user settings.xml, and gradle is now using the correct settings.

Comment by Gradle Forums [ 13/Feb/13 ]

unfortunately I can't reproduce the problem locally. I've defined a mirror in ~/.m2/settings.xml and in M2_HOME/conf/settings.xml and in my test project this does not affect the url mavenDeployer settings in my uploadArchive task.

Can you possibly share a settings.xml you're using and provide the gradle debug output of the uploadArchives task?


Comment by Gradle Forums [ 13/Feb/13 ]

I've created the following Gist - [1]https://gist.github.com/anonymous/494...

If this settings.xml is located in my user area, then the proxy setting is ignored, and I receive the following message:

Error deploying artifact 'bob:rita:gradle': Error deploying artifact: Error transferring file
Connection timed out: connect

If it is located in the system area, then the proxy setting is retained, and I receive the following message:

Error deploying artifact 'bob:rita:gradle': Error deploying artifact: Failed to transfer file: [2]http://www.google.com/bob/rita/1.0/ri.... Return code is: 405

If I run in debug mode, I see "Maven Ant Tasks version: 2.1.3" loading four settings.xml files, as detailed above.

It appears that the last one wins.
[1] https://gist.github.com/anonymous/4943911
[2] http://www.google.com/bob/rita/1.0/rita-1.0.gradle

Comment by Gradle Forums [ 13/Feb/13 ]

My problem is similar but I have a mirror defined in my M2HOME/conf/settings.xml

When I change the mirrorOf to not mirror * then it works fine.
It seems to me like the settings.xml has precedence over whatever is defined in build.gradle.

Comment by Gradle Forums [ 13/Feb/13 ]

I can reproduce this with the following settings.xml:

<name>UK Central</name>

Comment by Jonathan Baker [ 25/Nov/13 ]

I was experiencing something similar with a local repo override in my personal settings.xml:


When I ran gradle install or uploadArchives, my published artifacts were still going to /HOME/.m2/repository.

I discovered the problem is that if you do not have M2_HOME set in your environment, I believe that the maven ant-tasks must hit some exception, and not parse the local settings.xml. If you set an M2_HOME environment variable it appears to work correctly. I haven't had time to dig into the maven ant tasks source to verify the excpetion triggering, but when I added an M2_HOME environment variable, my artifacts were stored in the correct location.

I don't know if they are exactly the same problem, or not, but it seemed worthwhile to post my findings.

Comment by Jonathan Baker [ 25/Nov/13 ]

It looks like in this file if M2_HOME is not set, then it just loads the default Maven settings class (org.apache.maven.settings.Settings). The user and global settings are merged using org.apache.maven.settings.SettingsUtils.

There must be a bug in the merging algorithm when the one of the settings are default...

Comment by David Meibusch [ 25/Feb/14 ]

This may have been resolved in MANTTASKS-174, in Maven Ant Tasks 3.0.0-beta-1. At a glance the description looks a match.

In gradle 1.11, the Maven plugin appears to be using maven-ant-tasks 2.1.3.

Comment by Victor Ott [ 20/Aug/14 ]

We've also been hit by this issue, which looks to be duplicated by GRADLE-2877.
The solution David Meibusch suggested looks very promising. I wasn't able to find any nightly builds for maven-ant-tasks 3.0.0-1 beta yet, so I couldn't test it myself. Did somebody have more luck, and has tried it?

Generated at Wed Jun 30 12:28:34 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.