-----Original Message-----
From: Eric B [] 
Sent: Wednesday, February 14, 2018 8:27 PM
To: Maven Users List <>
Subject: Re: Looking for recommendations how to best use Maven in a muti-stage 
Pipeline build to only deploy at the end

Hi Robert,

Thanks for the suggestions.  To be honest, I never thought of using regular 
repositories as staging repos.  That being said, I do see a hiccup with the 
option that I'm not sure how to address.  In the case where a build is rejected 
during the pipelline stage, how do I delete it?  I haven't found a plugin that 
would allow me to delete a build from a repo.  And with a multi-module project, 
there are many artifacts that would need to be rolled back.  I guess I could 
simply configure the repo to allow re-deployment of the same artifact to these 
"stage" repos, but if ever a deployment fails part way through, I end up with a 
repo in an unstable manner (ie: there is no way to ensure that all modules are 
promoted at the same time).

[Robert] Typically, I would solve this problem by simply putting expiration 
dates on artifacts in the staging repositories.  I have never used Nexus but 
Artifactory allows you to limit artifacts in the repository by size, last time 
accessed, etc.  No need to keep artifacts in the "staging repositories" for 
more than say, one month, anyway since they were either good (and promoted all 
the way to the release repository) or bad (and are not interesting after they 

All that being said, the last question would be how to retrieve and redeploy 
these artifacts from one repo to another?  Changing the distributionManagement 
settings is simple enough, but how would I instruct maven to download all the 
modules from a multi-module build and then deploy them?  I guess I could hack a 
profile in the parent pom where the different modules are defined with a 
dependency:copy-dependencies goal, but how do I ensure all artifacts that were 
just downloaded are then deployed to the next repo in the stage?  I would think 
the only way to do this would be writing my own custom plugin, unless you can 
think of some other mechanism to accomplish this?

[Robert] Another way to do this is to use properties for the key values for the 
repository URLs in the <repositories> and <distributionManagement> sections of 
the POM.  You simply set a default value for the properties in the root POM 
(e.g., with appropriate values for the repositories used by the developers) and 
then override the property values with Maven command-line -Ds (or profiles) in 
the Jenkins build steps to handle pulling and promoting to the right places...



On Wed, Feb 14, 2018 at 10:01 AM, Robert Patrick <>

> While Nexus may not support "staging repositories", it certainly 
> supports more than one repository so why not just create one or more 
> repositories that serve as staging repositories.  For example,
> Pipeline Steps:
> 1.) Trigger a build based on source check-in and push to stage1 repo 
> if build "succeeds"
> 2.) Pull artifacts from stage1 repo, run stage 2 tests, and push to 
> stage2 repo if tests succeed.
> 3.) Pull artifacts from stage2 repo, run stage 3 tests, and push to 
> stage3 repo if tests succeed.
> 4.) Pull artifacts from stage3 repo, run UAT tests, and push to 
> release repo if tests succeed.
> -----Original Message-----
> From: Eric B []
> Sent: Wednesday, February 14, 2018 8:30 AM
> To: Maven Users List <>
> Subject: Looking for recommendations how to best use Maven in a 
> muti-stage Pipeline build to only deploy at the end
> I'm looking for recommendations for the best way to use Maven in a 
> multi-stage Jenkins pipeline build to deploy only at the end.  At the 
> moment, I'm using Sonatype Nexus 3.x, which means i don't have the benefit
> of staging repos.   Consequently, I have to ensure that the only released
> versions of my libraries/application are final - they've passed QA.
> Additionally, the team wants to ensure that the version numbers are 
> always incremental and every version in the repo is a consumable 
> version (ie: I cannot deploy a version 1.2.3 which has not passed 
> QA/Acceptance Tests, and furthermore, I cannot deploy a 1.2.2 followed by a 
> 1.2.4).
> What that requirement translates to is that I have to ensure that the 
> binary built is fully tested before promoting it to Nexus. (and that I 
> shouldn't be appending build numbers to the maven version number).
> In my mind, I would like to do something the following in a Pipeline build:
> stage('build') { steps { sh 'mvn clean install'} }
> stage('Confirm deploy to QA'){
> steps {
> checkpoint 'test server deployed'
> script {
> env.DEPLOY_TO_QA_TEST = input message: 'User input required',
> submitter: 'authenticated',
> parameters: [choice(name: 'Deploy to acceptance test server', choices:
> 'no\nyes', description: 'Choose "yes" if you want to deploy the QA 
> test server')]
> }
> }
> }
> stage('deployQA') {
> when {
> environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'
> }
> steps{
> /* deploy the build to a QA environment */  }
> }
> stage('Confirm deploy to UAT'){ // prompt user }
> stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance 
> Testing enviornment */}
> stage('Confirm publish to Nexus'){ // prompt user }
> stage('publish') {
>     steps {
>       // mvn deploy -DskipTests (just deploy - don't rebuild)
>     }
> }
> Basically, I want to design my Jenkins pipeline to be my staging process.
> The problem I have is I'm not sure how I can only deploy at the end of 
> the pipeline.  When maven runs the deploy lifecycle, it will run 
> through all the other stages and reassemble my binaries, which 
> technically are not longer the same as those that were approved.  So 
> consequently, my binary hashes that were approved earlier in the 
> pipeline are not the same hashes that are deployed in Nexus.
> I realize that i can probably do some work and use the Reproducible 
> Build plugin (
> 3A__zlika.github.io_reproducible-2Dbuild-2Dmaven-2Dplugin_&d=DwIBaQ&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> nSxyAsyxa1Izff8ULe7vW8u084madbci-hLPsiLpxeU&m=Og2S17jc02JRwm-oHae8UQmi
> Ig_ 
> ygbBRL0EQoB_Wvuw&s=zipmYyPLpmFYv1RsnquZtQMf0-HoYoix12SZj6gD2jM&e=), 
> but that too comes with drawbacks (I want build timestamps in my 
> Manifest files, and zip entries, etc).
> Am I sunk?  Is my only hope to wait until Sonatype releases Staging 
> repos for Nexus 3.x sometime in Q2?  Or is there some other way I can 
> work around this?
> How is everyone else handling this situation?
> Thanks for sharing.
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to