• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • m2release-plugin
    • None
    • n/a

      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.

          [JENKINS-30794] Support for nexus-staging-maven-plugin

          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.

          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.

          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?

          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?

            Unassigned Unassigned
            ahammar Anders Hammar
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: