Status: Closed (View Workflow)
Resolution: Not A Defect
As far as I can see, authentication for Nexus repository can only be given with url based authentication (http://user:pw@url).
It would be more useful to take the authentication from already configured repositories instead (settings.xml).
If Nexus is configured without anonymous access, the plugin returns 401.
yes, the reason for this is that this plugin doesn't run a maven reactor, but rather follows the maven conventions to read artifact information from a maven repository (http://docs.codehaus.org/display/MAVEN/Repository+Metadata). It knows nothing of pom.xml and settings.xml and other maven things.
The reason I built the plugin in the first place was to avoid bootstrapping the heavy maven just to find a couple of strings. I use it in a lot of deployment jobs which themselves don't run maven, but rather wget things for deployment or update metadata about future deployments.
Basically all the plugin does is a single HTTP GET of the maven-metadata.xml file, parses it and presents the information inside in a dropdown (or has some simple logic to select one of those versions automatically) and does some simple string concatenations to generate a few env vars.
It would be a lot of work for me to read and parse settings.xml files, or to integrate a maven reactor and I wouldn't want to do it anyway, because at the time I wrote this plugin there were others who already did that.
You can try this plugin instead if you like: https://wiki.jenkins-ci.org/display/JENKINS/Maven+Repository+Client
I myself haven't used that plugin, but it seems from the description it will do what you want.
could you confirm the behavior, that after the first click on "build" with an empty list, the plugin authenticates and shows the artifacts?
I don't think that should happen. It should either consistently fail or consistently work.
I assume you can read Java - here's the code that connects to your nexus:
It is literally those 15 lines that do all the magic of getting all artifact versions from a maven repository and I don't see how they would authenticate in one job run and not in the other. I construct the Basic Auth header in there.
As explained in the comments above this functionality will not be added easily and will defeat the purpose of keeping this a very light-weight plugin.
Please investigate the other available maven plugins.
Thanks for the quick support!
Yes, from the Java point of view, the Nexus URL will be given to the java.net.URL class 1:1. It doesn't make sense at all, that after a first click on "build" the 401 disappears and the artifacts are shown. Might it be possible, that Jenkins modifies known urls in backend?
I doubt that too. would be quite an invasive thing to do.
however there is a CookieManager as of java 1.6. And even though I have never used it I believe purely from reading the javadoc that it is being used for HttpUrlConnections by default. http://docs.oracle.com/javase/6/docs/api/index.html?java/net/CookieManager.html
Now if Jenkins somewhere else uses pure HttpUrlConnections and provides the authentication and nexus gives them a cookie back that could be reused by my connections without my implementing a single line of code, just based on the fact that all plugins run in the same JVM as jenkins and all others plugins.
Take this as a pure speculation, based on no facts other than reading between the lines of Java's documentation.
There is as strange behavior in this plugin: I used the plugin within a maven build job to present available nexus artifacts.
From the beginning, there is no artifact version presented - empty list, I see 401 errors in the log file instead.
If I click on "build" with this empty list, nothing happens - but suprisingly on the next try to build the project: the list is filled with the artifacts??