[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: |
|
Description |
Hi 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. |
Comments |
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 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? thanks! |
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 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. |
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. |
Comment by Gradle Forums [ 13/Feb/13 ] |
I can reproduce this with the following settings.xml: <settings> |
Comment by Jonathan Baker [ 25/Nov/13 ] |
I was experiencing something similar with a local repo override in my personal settings.xml: <settings> <localRepository>/nonstandard/local/repository/location</localRepository> </settings> 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 |