We should provide a solution for this.

William Wong's analysis of the problem is correct: http://jira.codehaus.org/browse/GRADLE-702?focusedCommentId=207376&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_207376

First of all, it's unclear to me whether or not this problem is a bug. Is this how Maven normally behaves? Or is this some peculiarity of the Maven Ant Tasks themselves? At any rate the obvious solution for the problem is to use a different id for the repository in the Gradle build file. This is what you'd have to do if you were using the Maven Ant Tasks in an Ant build file. In the worst case we'd fix this problem and then get a new complaint from some other user that their mirror settings were being disregarded.

At any rate we shouldn't be throwing away the settings file entirely. The other preferences derived from the settings file (proxies and authentication) do not override the choices made in the build file and only take effect if they are omitted from the build file.

The most straightforward solution is to copy the settings file and remove all of the proxy sections and hand that to the ant task instead of the empty one that we currently use. However there is a user-level settings file and a global settings file and both can live in multiple places (~/.ant/settings, ~/.m2/settings, etc.) so this fix is probably more pain that it's worth.

A better solution would be to subclass DeployTask and override the updateRepositoryWithSettings() method. The implementation would be something like:
updateRepositoryWithSettings(RemoteRepository repo) {
url = repo.getUrl()
id = repo.getId()
super.updateRepositoryWithSettings(repo)
if(url != null)

if(id != null)

}

Finally this whole problem might change given this comment in updateRepositoryWithSettings() from line 422 of org.apache.maven.artifact.ant.AbstractArtifactTask:

// TODO: actually, we need to not funnel this through the ant repository - we should pump settings into wagon
// manager at the start like m2 does, and then match up by repository id
// As is, this could potentially cause a problem with 2 remote repositories with different authentication info

The file in question can be found here: http://svn.apache.org/viewvc/maven/ant-tasks/tags/maven-ant-tasks-2.1.1/src/main/java/org/apache/maven/artifact/ant/AbstractArtifactTask.java?revision=965619&view=markup

We should allow the settings.xml to be reused from Gradle. I haven't thought about this in depth. You should have the options to:

• ignore it
• use it with the option to customize it by allowing hooks that get a settings object (which is initialized from the settings.xml) and can be customized. Certain elements in the settings.xml should be excluded from being used for initialization. We should use native Maven code for instantiating the settings.xml (Maven can the merge the different locations).

I think this is an important issues for seamless integration with Maven. In particular when we allow for importing pom.xml's.

Proxy settings seem to be completely ignored at the moment. I would personally prefer to have Gradle-specific proxy settings, but that option simply isn't available. It makes absolutely no sense to put the proxy settings in the build file.

Right now, I simply can't deploy artifacts to Maven repositories from work.

This seems like something that should be resolved for a 1.0 release.

It looks like some work progressed with the addition of MaybeUserMavenSettingsSupplier, but that's only called by BaseMavenInstaller.

Are there plans to get this into 1.0?

I am still experiencing this issue with the last release.
My settings file is loaded but the proxy settings are not taken into account.
With this issue, I can't use gradle to upload war from behind a corporate proxy.

Hello and sorry for the stupid question:
Isn't it possible to call maven "as it is"? So we don't have to configure all the maven settings or locations of maven's settings.xml but just call maven.
When I build a maven project I also don't have to configure maven explicit. Every configuration already perfectly is in my ~/.m2/settings.xml (and ~/.m2/settings-securtiy.xml). The first time I used mavenLocal() as repository I expected to use the whole maven not just my local repository.

btw: This is not only a problem of deplying but also for simple load dependencies

https://discuss.gradle.org/

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

still a blocking issue IMHO

I concur with Wolfgang Wachsmuth. I still have to workaround this issue and end up manually reading the settings.xml and then altering the task definition just before it runs like so:

uploadArchives {
        repositories.mavenDeployer {
                configuration = configurations.deployerJars
                repository(url: project.ext.isReleaseVersion ? "https://my.repository/artifactory/libs-release-local" : "https://my.repository/artifactory/libs-snapshot-local") {
                        authentication(userName:"ignored")
                }
        }
        doFirst {
                def settings = new File(System.getProperty('user.home') + '/.m2/settings.xml')
                if (settings.exists()) {
                        def xml = new XmlSlurper().parse(settings)
                        def server = xml.servers.children().find({ it.id.text() == 'myMavenServerId' })
                        if (server) {
                                def mavenUsername = server.username.text()
                                def mavenPassword = server.password.text()
                                println 'Found server definition, username: ' + mavenUsername
                                repositories.mavenDeployer.repository.authentication.userName = mavenUsername
                                repositories.mavenDeployer.repository.authentication.password = mavenPassword
                        } else {
                                println 'No server definition for artifacts was found in ' + settings
                        }
                } else {
                        println 'Maven settings file was not found: ' + settings
                }
        }
}

In the interest of backwards compatibility and users who would prefer to ignore their settings.xml I'd suggest that we simply provide a property on the task or the convention or something to instruct the task to use the user's settings.xml.

*Expected Behavior*
That there is an option to reuse settings.xml from Maven so that I could do this:

uploadArchives {
        repositories.mavenDeployer {
                configuration = configurations.deployerJars
                repository(url: "https://my.repository/artifactory/libs-release-local", id: "myMavenServerId")
        }
}

*Current Behavior*
The settings.xml is not consulted for authentication settings.

The issue is now tracked on GitHub: https://github.com/gradle/gradle/issues/1236