Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17717

Plugin should use authentication from settings.xml

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Activity

          oliver_2013 Oliver Fabry added a comment - - edited

          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??

          oliver_2013 Oliver Fabry added a comment - - edited 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??
          gesh Gesh Markov added a comment -

          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.

          gesh Gesh Markov added a comment - 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.
          oliver_2013 Oliver Fabry added a comment -

          could you confirm the behavior, that after the first click on "build" with an empty list, the plugin authenticates and shows the artifacts?

          oliver_2013 Oliver Fabry added a comment - could you confirm the behavior, that after the first click on "build" with an empty list, the plugin authenticates and shows the artifacts?
          gesh Gesh Markov added a comment -

          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:
          https://github.com/jenkinsci/maven-metadata-plugin/blob/master/src/main/lombok/eu/markov/jenkins/plugin/mvnmeta/MavenMetadataParameterDefinition.java#L196

          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.

          gesh Gesh Markov added a comment - 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: https://github.com/jenkinsci/maven-metadata-plugin/blob/master/src/main/lombok/eu/markov/jenkins/plugin/mvnmeta/MavenMetadataParameterDefinition.java#L196 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.
          gesh Gesh Markov added a comment -

          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.

          gesh Gesh Markov added a comment - 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.
          oliver_2013 Oliver Fabry added a comment -

          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?

          oliver_2013 Oliver Fabry added a comment - 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?
          gesh Gesh Markov added a comment -

          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.

          gesh Gesh Markov added a comment - 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.
          oliver_2013 Oliver Fabry added a comment -

          ok, thanks a lot!

          oliver_2013 Oliver Fabry added a comment - ok, thanks a lot!

          People

            Unassigned Unassigned
            oliver_2013 Oliver Fabry
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: