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

Support for nexus-staging-maven-plugin

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: m2release-plugin
    • Labels:
      None
    • Environment:
      n/a
    • Similar Issues:

      Description

      Staging support in Sonatype Nexus today is preferably handled via the nexus-staging-maven-plugin, which replace the default maven-deploy-plugin.

      It would be good with some support in m2release plugin for this by, for example, storing info on the created staging repo id. The nexus-staging-maven-plugin creates a properties file during execution (in the workspace) where this info is recorded:

      #Generated by org.sonatype.plugins:nexus-staging-maven-plugin:1.6.6
      #Mon Oct 05 13:35:43 CEST 2015
      stagingRepository.managed=true
      stagingRepository.profileId=ab12345cd67ef
      stagingRepository.id=test_staging-1001
      stagingRepository.url=http\://nexus.acme.org\:80/content/repositories/test_staging-1054

      What I'm thinking is that this info could then later on be used to promote/release or drop the staging repo programatically. The properties file is typically removed during the next Maven build (mvn clean install).

      We could also maybe depreacte the current Nexus Pro support in the plugin for automatically closing a staging repo as that is supported by the nexus-staing-maven-plugin out-of-the-box. Or that could be kept for those needing it and adding additional Nexus Pro/nexus-staging-maven-plugin support.

        Attachments

          Activity

          Hide
          teilo James Nord added a comment -

          I actually think supporting nexus pro using the nexus maven plugin woukd be a backward step.
          Why?
          1 you need to run maven to do anything for the stage (means the promotion could not be lightweight)
          2 you need to parse and recreate the files etc for this.

          The stage is already known about by the jenkins plugin, it was always my intention to expose this and then add an extra action to promote or drop the stage interacting directly with nexus.

          Show
          teilo James Nord added a comment - I actually think supporting nexus pro using the nexus maven plugin woukd be a backward step. Why? 1 you need to run maven to do anything for the stage (means the promotion could not be lightweight) 2 you need to parse and recreate the files etc for this. The stage is already known about by the jenkins plugin, it was always my intention to expose this and then add an extra action to promote or drop the stage interacting directly with nexus.
          Hide
          ahammar Anders Hammar added a comment -

          One basic reason for using nexus-staging-m-p and not just m-deploy-p is if you want to explicitly specify the stagingProfileId (and not have Nexus handle that implicitly). To my knowledge, that is not possible with the m-deploy-p way. The are other benefits as well, for example you don't have to configure use agent for different Jenkins nodes so that deployment is separated correctly.

          In any case, I'm not saying that we should use Maven for everything with staging i Nexus (although Sonatype support says it's the prefered way). Basically, what I'd like is the nexus-staging-m-p to be supported as well. To be able to do anything later on with the staged repo, you need the ID. In the nexus-staging-m-p case I think it's done easiest by parsing a properties file (which the plugin does as well). Not perfect, but I wouldn't mind talking to Sonatype to have this logic hidden in a library they provide (which then the plugin would use as well).
          Then additional functionality could be added to the jenkins plugin to promote/release or drop the repo. And this should work regardless of if the staging was done the m-deploy-p or the nexus-staging-m-p way.

          WDYT?

          Show
          ahammar Anders Hammar added a comment - One basic reason for using nexus-staging-m-p and not just m-deploy-p is if you want to explicitly specify the stagingProfileId (and not have Nexus handle that implicitly). To my knowledge, that is not possible with the m-deploy-p way. The are other benefits as well, for example you don't have to configure use agent for different Jenkins nodes so that deployment is separated correctly. In any case, I'm not saying that we should use Maven for everything with staging i Nexus (although Sonatype support says it's the prefered way). Basically, what I'd like is the nexus-staging-m-p to be supported as well. To be able to do anything later on with the staged repo, you need the ID. In the nexus-staging-m-p case I think it's done easiest by parsing a properties file (which the plugin does as well). Not perfect, but I wouldn't mind talking to Sonatype to have this logic hidden in a library they provide (which then the plugin would use as well). Then additional functionality could be added to the jenkins plugin to promote/release or drop the repo. And this should work regardless of if the staging was done the m-deploy-p or the nexus-staging-m-p way. WDYT?

            People

            • Assignee:
              teilo James Nord
              Reporter:
              ahammar Anders Hammar
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: