Romain Grécourt wrote on 10/12/18 01:06 PM:
    
      
      
        
          
            Have a look at the
              nexus-staging-maven-plugin.
              
             
         
       
    
    There's way too many options and choices there.  I'm really hoping
    someone else who really understands this stuff has figured out
    exactly how to do this for our Eclipse projects.
    
    
      
        
          
            
              
              
              
                            <plugin>
                               
                  <groupId>org.sonatype.plugins</groupId>
                               
                  <artifactId>nexus-staging-maven-plugin</artifactId>
                               
                  <extensions>true</extensions>
                                <configuration>
                                   
                  <serverId>ossrh</serverId>
                
                                </configuration>
                            </plugin>
               
              
              
              You can configure the plugin to automatically release
                the staging repository (autoReleaseAfterClose=true).
              I.e, this makes the nexus workflow transparent.
             
           
         
       
    
    I assume we 
don't want to do this because we need to wait
    for Release Review approval before releasing the staged artifacts.
    
    
      
        
          
            
              You could also implement the workflow manually.
                (skipStagingRepositoryClose=true) 
              
             
           
         
       
    
    I assume this is what we want.  Is this not the default?
The way I understand it the default configuration of the plugin will leave with a closed staging repository.
    
    
      
        
          
            
              It would look like something like this:
              
              
              
                # Create the nexus staging repository
                STAGING_DESC="Project ACME v${FULL_VERSION}"
                mvn nexus-staging:rc-open \
                  -DstagingProfileId=6026dab46eed94 \
                  -DstagingDescription="${STAGING_DESC}"
               
             
           
         
       
    
    Where does the stagingProfileId come from?
 
 
    
    How often do I need to create the staging repository?  Once ever? 
    Every time I want to stage something new?
Every time you deploy. Without using this plugin, nexus creates one on the fly.
This is why on 
maven.java.net you had to go to nexus and then close/release.
    
    
      
        
          
            
              
                STAGING_REPO_ID=$(mvn nexus-staging:rc-list | \
                  egrep "^\[INFO\] orgacme\-[0-9]+[ ]+OPEN[
                  ]+${STAGING_DESC}" | \
                  awk '{print $2}' | head -1)
               
             
           
         
       
    
    What is "orgacme" above?
 
This is the profile name. I got that value with rc-list-profiles (see above).
    
    
      
        
          
            
              
                # Perform deployment
                mvn deploy -DstagingRepositoryId=${STAGING_REPO_ID}
                
                
                # Close and release the nexus staging repository
                
                mvn nexus-staging:rc-close nexus-staging:rc-release
                  \
                  -DstagingRepositoryId=${STAGING_REPO_ID} \
                  -DstagingDescription="${STAGING_DESC}"
               
             
           
         
       
    
    Can I put the above in a Jenkins job separate from the "mvn deploy"
    command?  I'm not clear on what the lifetime is of the value in
    STAGING_REPO_ID.  If I compute it once in the "mvn deploy" job and
    again in the "rc-release" job, will it have the same value? 
 
Yes, you could automate the workflow with a difference job. 
Note that here I'm expecting only one staging repository so I grab the first one.
We could think of a convention in the staging repository description and match that with a parameter on the job.
E.g This job takes a version as parameter and the script uses that to match the right repository and complete the workflow.