Authentication with maven nexus with maven's settings.xml

(Wolfgang Wachsmuth) #1

tl/dr: How can I configure gradle build script to authenticate with maven nexus without storing passwords additional somewhere and without writing too much boiling code?

Hi there,

I come from the issue and I am really wondering if there is no way to use maven as it is with gradle.

My setup is following:
I have several android projects at different Git locations. There must not be a single wrapping project, we have to chose our modules by group/artifact/version.

At our office we use a own nexus. We have to authenticate with the nexus. Our company police says we have to encode our username password combination using maven’s settings-security.xml. When using maven everything is working fine. Maven checks the settings.xml deodes the authentication tokens with settings-security.xml, choses the correct nexus/mirror URL and fetches dependencies.

Now this is what I hoped to get when writing

repositories {

but sadly this only makes gradle look up in the local repository configured in the settings.xml (please correct me, if I’m wrong).

To make this all possible with gradle projects I wrote a plugin reading the settings, decoding password phrase and authenticating with nexus. The only problem: This plugin must be published to our nexus and all the other projects can’t authenticate with nexus without the plugin (lol).

So this is quite a dilemma. Of course our ci server jenkins shall build all the projects, everyone shall be able to checkout a module and build it instantly (requirements are configured maven and installed gradle).
Could you please give me some hints or best practices how to solve this issue? I really thought this may be a common problem but I couldn’t find a reasonable answer yet.

Thanks a lot

(Wolfgang Wachsmuth) #2

Sorry for bumping:

So this isn’t an issue for anyone?
Sad news but okay


(Mark Vieira) #3

There is a plugin for this, however if your company doesn’t allow going out to external repositories you have the same problem. Another option would be to implement this with an init script rather than a binary plugin, or host the plugin in a repo that doesn’t require authentication.

(Wolfgang Wachsmuth) #4

Hi mark,
thanks for your reply! I already tried out this plugin. Sadly it only supports basic authentication. Well, we have to investigate some work around like you mentioned. Maybe I am just a bit stubborn and I need to rethink how to gradle up my project.

(Mark Vieira) #5

It could be improved to support certificate authentication but only in conjunction with the ‘maven’ plugin. Unfortunately the ‘maven-publish’ plugin only supports username/password based auth.

(Wolfgang Wachsmuth) #6

Hey mark, thanks for answers!

Does this mean, it supports encrypted password encrypted by master password in ~/.m2/settings-security.xml?
Or isn’t this basic authentication anymore?
One of the main problems is our policy, which I agree, disallowes us to use plain text files with our real passwords.

(Mark Vieira) #7

That is correct. Encrypted credentials are property decrypted using the master password in settings-security.xml. By “basic” authentication I mean username/password based auth.

(Wolfgang Wachsmuth) #8

Hey Mark,

thanks a lot, so I should to give maven-settings another try :sweat_smile:
I may have configured it wrong in the past.

(steve) #9

There is also a plugin I write and maintain. It works with both the new and old publishing model.

Unfortunately an optimal solution requires Gradle itself to make credential information available, meaning Maven settings creds should really just be a source for the cred stuff Gradle dev team is working on. I had discussions with Hans and Adam about this back when I first wrote that plugin. But as far as I know there recent work on credential support in Gradle still does not allow for such use cases.

(Mark Vieira) #10

We’ve started preliminary design of the notion of credential “providers” which I think is what this use case would fall under.

(DC) #11

Hi Mark,

Is there any update on the credential “providers”? Is this still in the design stage? The kerberos and NTLM credentials are of particular interest to me.

Thank you,

(Mark Vieira) #12

I’m going to call in my dear friend @eriwen here :wink:

(DC) #13

might try calling @eriwen on twitter :slight_smile:

(Eric Wendelin) #14

Hey fellas, I’m out for a couple days with an injured back so I’ll be (sorta) brief.

It sounds like you’re referring to Work on this has not been started yet, but 1 of our top 2 priorities for the latter half of 2017 is streamlining Maven migration. It sounds like this issue is a good candidate for that effort.

Please upvote or helpful context to that GitHub issue if you feel compelled. Further, if this is something you’d be interested in contributing, we’d welcome your help.