Re: Maven CI Friendly Versions

[Eric Benzacar]

Thanks Tamás!

Eric

On Fri, Nov 10, 2023 at 11:24 AM Tamás Cservenák 
wrote:

> It changed domain
>
> https://blog.soebes.io/posts/2017/04/2017-04-02-maven-pom-files-without-a-version-in-it/
>
> HTH
> T
>
> On Fri, Nov 10, 2023 at 5:19 PM Eric B  wrote:
>
> > Many years ago Karl Heinz Marbaise had written a blog about the beginning
> > of Maven 3.5's support of CI versioning numbers with the specific
> > parameters that are interpolated by maven.  I always used to refer new
> > developers to that blog that were trying to understand the complexities
> of
> > using Maven and versioning in a CI environment.
> >
> > It used to be hosted at: http://blog.soebes.de/blog/2017/04/02/maven
> > -pom-files-without-a-version-in-it/
> > <
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
> >
> >
> > But that site is now unfortunately dead (404).
> >
> > I had always found that it was a very good intro to the problem and
> helped
> > clarify things well, including the need for using the flatten-plugin,
> etc.
> >
> > Does anyone know if that blog is still available, but posted elsewhere,
> or
> > alternatively any good sites to help newcomers to the CICD problems with
> > Maven?  Clearly, there is the default documentation on Maven itself (
> > https://maven.apache.org/maven-ci-friendly.html) but is anything
> > additional
> > that I can reference newcomers to?
> >
> > Specifically, I am looking for best-practices for automated Jenkins
> > builds/pipelines/etc when integrated with CI variables.
> >
> > Thanks!
> >
> > Eric
> >
>

Re: Looking for recommendations how to best use Maven in a muti-stage Pipeline build to only deploy at the end

[Eric Benzacar]

Robert,

I think you misunderstood my problem.  It isn't a problem of defining
different distributionManagement repos; like you said that is fairly easily
handled using properties or -D parameters.

It is more the question of what kind of plugin is required to run which
says:
- download all the artifacts that this multi-module project previously built
- deploy all the artifacts that were just downloaded

I cannot think of how to design/configure a project to accomplish something
like that.  I'm guessing I would have to create a profile which explicitly
declares each artifact produced by the multi-module project in order to do
a dependency:copy, and then similarly, use a build-helper:attach all the
artifacts that were just downloaded.  But that seems like a painful
solution.  Am hoping there is something easier?

Thanks,

Eric


On Wed, Feb 14, 2018 at 9:45 PM, Robert Patrick 
wrote:

> Inline...
>
>
> -Original Message-
> From: Eric B [mailto:ebenza...@gmail.com]
> 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 fail).
>
> 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  and 
> 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...
>
> Thanks,
>
> Eric
>
>
>
> On Wed, Feb 14, 2018 at 10:01 AM, Robert Patrick <
> robert.patr...@oracle.com>
> wrote:
>
> > 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 [mailto:ebenza...@gmail.com]
> > 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 

Re: Looking for recommendations how to best use Maven in a muti-stage Pipeline build to only deploy at the end

[Eric Benzacar]

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).

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?

Thanks,

Eric


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

> 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 [mailto:ebenza...@gmail.com]
> 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 (https://urldefense.proofpoint.com/v2/url?u=https-
> 

Re: Is it poor practice to use Maven repo (ie: Nexus) to store non maven artifacts?

[Eric Benzacar]

Thanks for the suggestions/confirmations.  Not a bad idea to create a basic
pom with the build-helper plugin; it'll allow me at the very least to add a
little documentation as to what the artifact is.

Eric


On Mon, Nov 27, 2017 at 12:03 PM, Andrew Todd 
wrote:

> In order to keep track of what you've uploaded and allow consistent uploads
> of new versions, I recommend that you create a POM file for each binary
> artifact and define an execution of the
> http://www.mojohaus.org/build-helper-maven-plugin/ attach-artifact goal to
> perform the upload.
>
> On Sun, Nov 26, 2017 at 3:52 PM, Manfred Moser 
> wrote:
>
> > I think it is a common and good practice. Specifically if you take
> > advantage of using a good structure in terms of the use GAV coordinates
> and
> > release versioning. And also with regards to potentially restricting
> access
> > based on that..
> >
> > manfred
> >
> > Eric B wrote on 2017-11-26 11:36:
> >
> > > I have a need to store some binary objects (ex: zip files) in a central
> > > repository that can be easily accessed by a build or deployment system.
> > > Both Chef and/or Docker need access to these binary objects in order to
> > > build out the environment needed for my application.
> > >
> > > The binary objects are not code or libraries.  They are purely a zip
> file
> > > of static resources (ex: gifs or help documentation/templates/etc,
> GeoIP
> > > database, etc).  I need them somewhere centrally accessible so that my
> > > deployment system can easily retrieve them and explode them in the
> > > container/environment to make accessible to my application.
> > >
> > > At the moment, they are being hosted in a "raw" Nexus repo.  But the
> > > problem with a raw repo is that there is no classification of
> > > artifacts/versioning/etc.  So I am considering giving them all a GAV id
> > and
> > > putting it in the Maven repo as a maven artifact.
> > >
> > > But is this poor practice?  I've always considered Maven artifacts as
> > > "code-related" - that is artifacts that are the output of some code
> > > development.  Could be compiled sources, javadocs, generated artifacts,
> > > etc.  But putting in these static binaries just seems "wrong".
> However,
> > I
> > > don't really see a good alternative.
> > >
> > > I realize that this "can" be done.  I guess my question is rather
> > "should"
> > > it be done?  How is everyone else handling these types of resources?
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Special parameters - sha1

[Eric Benzacar]

Thanks for the insight; I guess that's kind of what I was doing with the
sha1/build number.  I would end up with a 5.0.0-1a2b3c4d which would make
it a unique,random number.

I may end up rethinking this though based on some of the insights you
shared.

Thanks,

Eric

On Fri, Nov 17, 2017 at 4:13 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Fri 17 Nov 2017 at 21:07, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> >
> > On Fri 17 Nov 2017 at 13:57, Eric B <ebenza...@gmail.com> wrote:
> >
> >> Hi Bernd,
> >>
> >> Thanks for the insight.  I understand what you mean, and to be honest,
> not
> >> entirely sure how to deal with that yet.  At the moment, it isn't a huge
> >> deal for me since my project is fairy self contained.  I have an API
> >> module
> >> which I need to version independently, but other than that, there are no
> >> artifacts produced that are consumed outside of my project... yet.
> >>
> >> But my issue is that I really dont know how to best handle this
> situation.
> >> At the moment, I am forced to build my release branch in snapshot mode
> >> which is aggravating.  I'm on Nexus 3 which doesn't support staging
> repos
> >> yet, and I've already generated at least 20+ builds from this release
> >> branch.  I can't keep rolling my semantic version number each time ...
> My
> >> business stakeholders would have a fit seeing version 5.0.63 being
> >> released
> >> instead of 5.0.0.
> >>
> >
> > Education is the solution...
> >
> > Educate them on what that 3rd digit means and why they want it high not
> low
> >
>
> At one company we used to routinely just add random amounts to the
> build/patch segment just so that stakeholders would be forced to stop
> assuming sequential versions.
>
> Otherwise you end up having to discuss “we need to re-release 5.0.0 because
> of a critical bug” and you never want to reuse a version number... like
> ever.
>
> So the least significant segment should be strictly incremental... does not
> need to be a constant increment.
>
> If the business needs X.Y.Z to be specific values then add another segment
> for the build number
>
>
> >
> >> Are there other recommended processes to use instead? Nexus 2 staging
> >> repos
> >> dealt with all this very neatly, but with that not coming to v3 for at
> >> least 2 more quarters I need to put together a more functional solution.
> >>
> >> Thanks
> >>
> >> Eric
> >>
> >> On Nov 16, 2017 12:50 AM, "Bernd Eckenfels" <e...@zusammenkunft.net>
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > If you have a POM with dependencies to other modules which are built
> on
> >> > each change, you typically want to make sure you use those updated
> >> > dependencies when you compile your projects.
> >> >
> >> > With regularly changing version numbers and without using SNAPSHOT
> >> > dependencies you will need to find a solution for this. You could use
> >> > version ranges, but then you are not much different then using
> SNAPSHOT
> >> > builds. This is one of the main reasons why we are doing manual
> >> releases -
> >> > and managing the dependency versions by hand.
> >> >
> >> > Gruss
> >> > Bernd
> >> > --
> >> > http://bernd.eckenfels.net
> >> > 
> >> > From: Eric Benzacar <e...@benzacar.ca>
> >> > Sent: Thursday, November 16, 2017 5:05:45 AM
> >> > To: Maven Users List
> >> > Cc: i...@soebes.de
> >> > Subject: Re: Special  parameters - sha1
> >> >
> >> > I'm not sure what you mean when you say:
> >> >
> >> > "How are you planning to deal with the changed version numbers of
> >> > dependencies?"
> >> >
> >> > At which stage are you referring to?  Which dependencies with changed
> >> > version numbers?
> >> >
> >> > Thanks,
> >> >
> >> > Eric
> >> >
> >> > On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <
> >> e...@zusammenkunft.net>
> >> > wrote:
> >> >
> >> > > You have to remember that POMs are also the model to describe
> >> artifacts,
> >> > > that why you should stay clear of profiles (especially

Re: Special parameters - sha1

[Eric Benzacar]

I'm not sure what you mean when you say:

"How are you planning to deal with the changed version numbers of
dependencies?"

At which stage are you referring to?  Which dependencies with changed
version numbers?

Thanks,

Eric

On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels 
wrote:

> You have to remember that POMs are also the model to describe artifacts,
> that why you should stay clear of profiles (especially if the influence
> artifact coordinates).
>
> Personally I have good experience with actually releasing things, but if
> you want to keep the build identifier, then I would agree, that handling
> this in the build job is probably the best. You can have even two
> Parameterized jobs.
>
> How are you planning to deal with the changed version numbers of
> dependencies?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B 
> Sent: Wednesday, November 15, 2017 4:30:06 AM
> To: i...@soebes.de; Maven Users List
> Subject: Re: Special  parameters - sha1
>
> Hi,
>
> Thanks for the additional insight.  I think I understand better now how
> this works.   I'll try to explain my use case, and perhaps someone can
> provide some ideas for best practices.
>
> I started a pom refactoring because I wanted to add the enforcer-plugin for
> a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> dev purposes, we have defined that anything in a release/ branch (Gitflow)
> is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> Additionally, we use semantic versioning, so our versions read 4.7.0,
> 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
> branch needs to have a unique version.  I don't want to update the version
> number for each build, so each build has to have a build number or sha1
> attached to the version.
>
> My build pipeline is very basic for the moment; it's a simple Jenkins
> freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
> simple as possible and always pass the same parameters to the maven build
> process (to make it easier for others to understand).
>
> I'm passing the following parameters to the maven build:
>  -DbranchType=release
>  -DbuildNumber=
>
> maven.config:
> -Drevision=5.0.0
>
>
>
> My thought process is I could do the following - for the normal use case
> (ie: dev branch):
> ${revision}${changelist}
> 
>   -SNAPSHOT
> 
>
>
> For a release:
> 
>   relelase
>   
> 
>branchType
>release
> 
>   
>
>   
>   ${buildNumber}
>
> 
> 
>
>
> But now I see that won't work.  So I need to pass the buildnumber on the
> command line as a SHA1 parameter.  But if I do that in this design, the
> SNAPSHOT will also include the SHA1 which is not what I want.
>
> So from what I can see, the only option is to modify the parameters on the
> command line.  Which means I have to add some additional logic to my
> Jenkins build.  This would be much easier if I had a Pipeline build but I
> don't at the moment.  I was just looking to put the intelligence in the pom
> so that anyone could easily read & understand it.
>
> Any suggestions or recommendations would be greatly appreciated.  Is there
> anyway to do this in the pom itself?
>
> Thanks,
>
> Eric
>
> On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> >
> > I will give some more details cause I have created the docs /
> > implementation and you mentioned my blog ;-)..
> >
> >
> > On 14/11/17 03:12, Eric B wrote:
> >
> >> Following a long thread on this list, and a blog by khmarbaise (
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/),
> >> I'm still a little confused as to exactly what is allowed in the special
> >> version tags for a maven pom.
> >>
> >> I know and realize that the 3 allowable tags are:
> >>   - ${revision}
> >>   - ${sha1}
> >>   - ${changelist}
> >>
> >> However, from the thread and the blog, it seems that these properties
> >> cannot be dependent on any other properties.
> >>
> >
> > Correct.
> >
> >>
> >> For example, this is fine:
> >> ${revision}-${sha1}
> >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> >>
> >>
> >> However, based on the further docs at
> >> https://maven.apache.org/maven-ci-friendly.html, this design would
> fail:
> >>
> >
> > which is not mentioned in the docs...
> >
> >
> >> ${revision}-${sha1}
> >>
> >> 
> >>   ${buildNumber}
> >> 
> >>
> >>
> >> and call it as -Drevision=1.2.3 -DbuildNumber=9
> >>
> >
> > The problem is simply that buildNumber is not correctly overwritten from
> > command and not correctly handled duing the model reading / interpolation
> > at the correct time within Maven Core at the moment...
> >
> > At the moment this is only implemented for those special three
> > properties...which already has performance impacts...which is also a
> reason
> > not 

Any way to activate a profile based on a property substring?

[Eric Benzacar]

Is there any way to use a substring of a property for profile activation in
Maven? I'm looking to use Jenkins to simply pass the branch name to my
build, and have a profile activated if it is a release/* branch.

Is there any way I can do parameter manipulation/regex like this for
profile activation? Ex:

  

  appserverConfig-dev
  

  branch

  
  release/.*

  
  
/path/to/dev/appserver
  

   

Or is there a different/better approach that I can use to only activate the
profile if the build is coming from a release branch?


Thanks


Eric

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

Hi Guys,

Sorry to reopen a 6 month old thread, but I'm trying to add some more
smarts to my stuff, and am failing trying to figure out how to do this.

I want to use the buildnumber-maven-plugin:create-metadata goal  to
generate the metadata build.properties file, which is a great addition to
my artifacts.  At the same time, I noticed that it contains some useful
information that I would want to use in my version number - such as the
sha1.

But the problem is that I can't figure out how to consume the metadata for
my version.  Basically, I need to get maven to know the sha1 from my
commit.  But the metadata file won't be interpolated by maven.  And if I
use the buildnumber:create goal to get the sha1, I can configure it to be
exported as a ${sha1} property.  And from everything I've understood, the
ONLY properties understood by maven for the  tag are ${revision}
${changelist} and ${sha1}.

But when I actually run the build all the interpolated version numbers
ignore the ${sha1} property as generated by the buildnumber-m-p, even
though I bound the create to the validate phase.

Although I am not extremely surprised by this, I was sincerely hoping there
was some way to make this work.  Is there any way at all to be able to
leverage what the buildnumber-m-p generates as part of my ?  Is
the only option to pass the ${sha1} value on command line?


A snippet of my pom:


test
org.project
${revision}${sha1}${changelist}


5.0.0







org.codehaus.mojo
buildnumber-maven-plugin
1.4


generate-sha1
validate

create



sha1

-{0}

scmVersion

8



generate-metadata
generate-resources

create-metadata


${revision}${sha1}${changelist}
true
true
META-INF/build.properties




no.scm.config.in.pom









Thanks!

Eric


On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran <dant...@gmail.com> wrote:

> Hi Eric
>
>
> i am using the follow at top level parent
>
>   ${revision}
>
>   
> x.y.x-SNAPSHOT
>   
>
> In child pom
>
>   
>   ...
>   ${revision}
>   
>
>
> At jenskins file
>
>   I have a param  releaseVersion by default it is empty
>
> if the releaseVersion is not empty, then pass
> -Drevision-${params.releaseVersion} into maven build
>
>
> This mean i have 3 modes
>
>- Default SNAPSHOT build
>- User can pass in the release version
>- Auto incremental release build where I update and commit jenkins file
> to default release version to 'x.y.z-${BUILD_NUMBER}'.
>
>
> I have team that will never use auto incremental release build, and they
> will manually run the build with a release version of their choice ( mode
> #2)
>
>
> -Dan
>
>
> On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar <e...@benzacar.ca> wrote:
>
> > Dan,
> >
> > Thanks for the update.  I'm at the state where I am trying to integrated
> CD
> > with a large multi-module maven project and trying to get this process
> > running smoothly with Jenkins.  For the moment, I'm ok to use a
> > split-Continuous Deployment concept - similar to yours.  ie: using
> > SNAPSHOTs for development phase, and anything in a release branch becomes
> > an release candidate.  Meaning that any commits into the release/ branch
> > produce a potentially shippable version.
> >
> > But that means that I need poms with version numbers as moving targets
> (ie:
> > sometimes with SNAPSHOTs, sometimes without).  Based on Karl Heinz
> > Marbaise's suggestions, I am planning on building my poms as follows:
> >
> > parent pom:
> >
> > com.benze
> >   parent
> >   ${revision}${sha1}${changelist}
> >   pom
> >
> >   
> > 1.3.1
> > -SNAPSHOT
> > 
> >   
> >
> >
> > but in my child poms, I'm not sure how to refer to the parent:
> >
> > webapp
> > war
> > 
> >com.benze
> >parent
> > ??? 
> >../superpom
> > 
> >
> >
> >
> > How do you refer to the parent pom with a constantly (non-defined) moving
> > version?  In the past, without using properties like this, I could use
> the
> > maven-versions-plugin to update the version numbers, but now I don't even
> > see how I can do that.  If the revision is defined at the command line in
> > Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms?  If
> > memory serves, the child cannot use properties for the parent version
> > number.
> >
> > How/where to do you specify your semantic version number?  I remember you
> > said you use the buildnumber-m-p for the build number, but that
> > how/where/when do you specify the sematic version number?  Do you have to
> > manually change it in the poms at RC time?  Is it only defi

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

Dan,

Thanks for the update.  I'm at the state where I am trying to integrated CD
with a large multi-module maven project and trying to get this process
running smoothly with Jenkins.  For the moment, I'm ok to use a
split-Continuous Deployment concept - similar to yours.  ie: using
SNAPSHOTs for development phase, and anything in a release branch becomes
an release candidate.  Meaning that any commits into the release/ branch
produce a potentially shippable version.

But that means that I need poms with version numbers as moving targets (ie:
sometimes with SNAPSHOTs, sometimes without).  Based on Karl Heinz
Marbaise's suggestions, I am planning on building my poms as follows:

parent pom:

com.benze
  parent
  ${revision}${sha1}${changelist}
  pom

  
1.3.1
-SNAPSHOT

  


but in my child poms, I'm not sure how to refer to the parent:

webapp
war

   com.benze
   parent
??? 
   ../superpom




How do you refer to the parent pom with a constantly (non-defined) moving
version?  In the past, without using properties like this, I could use the
maven-versions-plugin to update the version numbers, but now I don't even
see how I can do that.  If the revision is defined at the command line in
Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms?  If
memory serves, the child cannot use properties for the parent version
number.

How/where to do you specify your semantic version number?  I remember you
said you use the buildnumber-m-p for the build number, but that
how/where/when do you specify the sematic version number?  Do you have to
manually change it in the poms at RC time?  Is it only defined during the
build process?

Do you have an example of your pom structure and Jenkinsfile pipeline that
you can share to help me better grasp how to handle this integration?

Thanks,

Eric



On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran  wrote:

> Just want to share our final outcomes
>
> 1. Use snapshot build during development phase
>
> 2. At release candidate phase, switch jenkinsfile to release mode
>
> * For small projects, use version less Maven continuous deliver
> friendly,
>
> * For large projects, use  versions-maven-plugin to change version in
> all poms at pre-build
>
> * Automate the process to tag the final RC (we deploy a
> build.properties to maven repo at each build, use its info to tag the SCM)
>
> Whenever, the startup performance issue for large project is fixed, we will
> switch to full version less build
>
> -Dan
>
> On Sun, May 14, 2017 at 7:23 PM, Dan Tran  wrote:
>
> > I also noticed it takes about a minute for the build to roll after this
> >
> > [INFO] Error stacktraces are turned on.
> > [INFO] Scanning for projects...
> >
> > This is not a good news for local dev build
> >
> > here are 2 time summaries running 250+ modules with skipTests and 4
> thread
> > smart builder. The first one does not use ${revision}
> >
> > [INFO] 
> > 
> > [INFO] Total time: 04:05 min (Wall Clock)
> > [INFO] Finished at: 2017-05-14T19:16:32-07:00
> > [INFO] Final Memory: 680M/2078M
> >
> > [INFO] 
> > 
> > [INFO] Total time: 05:56 min (Wall Clock)
> > [INFO] Finished at: 2017-05-14T19:11:00-07:00
> > [INFO] Final Memory: 1726M/3561M
> >
> >
> > -D
> >
>

Re: Jenkins Maven build not seeing my .mvn folder?

[Eric Benzacar]

Thanks for the links and the info, but after reading MNG-5889, I'm even
more confused.

Am I to understand that MNG-5889 is specifically regarding Maven to look
for the .mvn folder in the directory of the invoked pom file rather than in
the current working directory?  Will this break my current structure in
which my .mvn folder is in my project root rather than the parent-pom
folder?

What is the "right" structure for something like this?

Thanks,

Eric


On Tue, Jun 6, 2017 at 2:31 PM, Arnaud Héritier  wrote:

> It is https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5889
>
>
> Le mar. 6 juin 2017 à 20:27, Arnaud Héritier  a
> écrit :
>
> > The problem with extensions is different. And I don't think we'll fix it.
> > The problem .mvn and usage of -f is a maven bug fixed in 3.5.0 or 3.5.1
> >
> > Le mar. 6 juin 2017 à 19:36, Pascal  a écrit :
> >
> >> The existing bug to support core extensions:
> >> https://issues.jenkins-ci.org/browse/JENKINS-30058
> >>
> >> As I said, the only solution so far is to use a Freestyle project. You
> can
> >> find more details in the bug comments.
> >>
> >> Pascal
> >>
> >>
> >> 2017-06-06 19:27 GMT+02:00 Pascal :
> >>
> >> > Hello,
> >> >
> >> > I fear you have done everything correctly and the issue is with the
> >> > Jenkins Maven plugin. There is already a bug report in the Jenkins
> Maven
> >> > Plugin, but it's hard to find. If I recall how to find it, I will post
> >> it
> >> > here.
> >> >
> >> > Unfortunately, it does not look like an easy bug, so you cannot use
> the
> >> > "Maven" Job type in Jenkins together with the .mvn folder feature.
> >> However,
> >> > what you can do is create a Freestyle Job and add a build step "Call
> >> Maven
> >> > goals".
> >> >
> >> > Cheers,
> >> >
> >> > Pascal
> >> >
> >> >
> >> > 2017-06-06 18:13 GMT+02:00 Eric B :
> >> >
> >> >> Hi,
> >> >>
> >> >> I'm cross posting this to StackOverflow (
> >> >> https://stackoverflow.com/q/44394234/827480) b/c I'm not truly
> >> convinced
> >> >> this is a maven question per say.  Rather I think it is more
> something
> >> due
> >> >> to my Jenkins job config that is causing some issues, but I am hoping
> >> that
> >> >> maven users here may have encountered this in Jenkins as well.
> Either
> >> >> that, or maybe someone can point out that I'm using the .mvn folder
> >> >> incorrectly.
> >> >>
> >> >> Essentially, I have a multi-module maven project that is set up as:
> >> >>
> >> >> |.mvn
> >> >>  \-maven.config
> >> >>  \-jvm.config
> >> >> |superpom
> >> >>  \-pom.xml (main project parent pom, includes module defns)
> >> >> |module1
> >> >>  \-pom.xml (parent points to ../superpom/pom.xml)
> >> >>  \src
> >> >>   \...
> >> >> |module2
> >> >>  \-pom.xml (parent points to ../superpom/pom.xml)
> >> >>  \src
> >> >>   \...
> >> >>
> >> >> My maven.config file is defined as:
> >> >>
> >> >> -Dsign.alias=cert
> >> >> -Dsign.storepass=changeit
> >> >> -Dsign.keypass=changeit
> >> >> -Dcheckstyle.skip=true
> >> >> -Dcobertura.skip=true
> >> >> -Dpmd.skip=true
> >> >> -DskipTests=true
> >> >> -DdatabaseUrl=jdbc:sqlserver://localhost:1433;databaseName=TEMP
> >> >> -DuserName=test
> >> >> -Dpassword=test
> >> >> -f superpom/pom.xml
> >> >>
> >> >> If I run my maven build from the command line, everything builds as
> >> >> expected. ie:
> >> >>
> >> >> [project]$ mvn clean install
> >> >>
> >> >> However, when I configure my jenkins job, it is failing as though it
> is
> >> >> not
> >> >> seeing/reading the .mvn/ folder/files. In fact, to be honest, I'm not
> >> >> entirely sure how to configure my maven project in Jenkins. If I
> leave
> >> my
> >> >> ROOT pom definition as blank, then Jenkins complains it doesn't have
> a
> >> >> pom.xml file.
> >> >>
> >> >> If I specify my root pom as superpom/pom.xml then it isn't loading
> any
> >> of
> >> >> my config files.
> >> >>
> >> >> To be safe, I've even tried adding my .mvn folder in my superpom
> >> folder,
> >> >> but that too is ignored.
> >> >>
> >> >> jenkins.log:
> >> >>
> >> >> [superpom] $ /var/jenkins_home/tools/hudson.model.JDK/JDK_7/bin/java
> >> >> -cp /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-
> >> >> agent-1.8.1.jar:/var/jenkins_home/tools/hudson.tasks.Maven_
> >> >> MavenInstallation/Maven_3.3.9/boot/plexus-classworlds-2.5.2.
> >> >> jar:/var/jenkins_home/tools/hudson.tasks.Maven_
> >> >> MavenInstallation/Maven_3.3.9/conf/logging
> >> >> jenkins.maven3.agent.Maven33Main
> >> >>
> >> /var/jenkins_home/tools/hudson.tasks.Maven_
> MavenInstallation/Maven_3.3.9
> >> >> /var/jenkins_home/war/WEB-INF/lib/remoting-3.7.jar
> >> >> /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-
> >> >> interceptor-1.8.1.jar
> >> >> /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven3-
> >> >> interceptor-commons-1.8.1.jar
> >> >> 38679
> >> >> <===[JENKINS REMOTING CAPACITY]===>channel started
> >> >> 

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

 the first glance)
>
> But now I have given mvn -Drevision=2.0.0 install
>
> There will produced also files like this:
>
> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0-
> SNAPSHOT/parent-2.0.0-SNAPSHOT.pom
>
> The pom file will look like exactly the same:
>
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> which is obviouly wrong(the same is if you omit the revision,
> changelist and sha1 from properties part).
>
> If you like to consume this pom file it will fail cause this can't be
> correctly solve (where is the -Drevision=2.0.0 gone?)
>
>
> That is the reason you need the flatten-maven-plugin cause it replace the
> propreties in the version tag with it's current version (can do more but
> that's a different story) and produce a correct pom file:
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns="
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>   4.0.0
>   com.soebes.examples.j2ee
>   parent
>   2.0.0-SNAPSHOT
>   pom
>   
> 
>   Apache License 2.0
>   http://www.apache.org/licenses/LICENSE-2.0.txt
>   repo
> 
>   
>
> which is now consumeable by any kind of tool etc. also Maven itself for
> example as a dependency
>
> I hope it makes this more clear...
>
> If not please ask/suggest improvements about the docs or what you need to
> know
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
>
>
>
> On 08/05/17 14:29, Stephen Connolly wrote:
>
>> On Mon 8 May 2017 at 03:58, Eric Benzacar <e...@benzacar.ca> wrote:
>>
>> Hi,
>>>
>>> Interesting.  Would something like this be functional then?  It seems to
>>> work, but I don't know if it is working as expected, or by fluke:
>>>
>>> com.soebes.examples.j2ee
>>> parent
>>> ${revision} pom .. 
>>> 
>>> 1.2.1-${buildNumber}
>>> SNAPSHOT
>>> 
>>>
>>>
>>> Then at the command line, I can either set the buildNumber in the case
>>> of a
>>> build:
>>> mvn installl -DbuildNumber=12345
>>>
>>> This works, but I don't know if I am using this as designed/expected.
>>>
>>
>>
>> Nope it only *appears to work*
>>
>> If you dig deeper you will see it is not working.
>>
>> The properties *must* be provided either on the CLI or by an extension. At
>> least as I understand it
>>
>>
>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>> On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels <e...@zusammenkunft.net>
>>> wrote:
>>>
>>> Hello,
>>>>
>>>> Only those specific properties are allowed. If I remember correctly the
>>>> reason for it is a mixture between it is not possible to support full
>>>> property resolving in this stage of the model builder and the intention
>>>>
>>> to
>>>
>>>> harmonize/restrict to familiarly named usecases.
>>>>
>>>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=
>>>> blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/
>>>> interpolation/AbstractStringBasedModelInterpolator.java;h=
>>>>
>>>> b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d7
>>> 8a8bd78ff9f0c7
>>>
>>>> 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb=
>>>> 181b0215aa1199e152db9d2c08b1a01436547805
>>>>
>>>> Gruss
>>>> Bernd
>>>> --
>>>> http://bernd.eckenfels.net
>>>> 
>>>> From: Eric Benzacar <e...@benzacar.ca>
>>>> Sent: Monday, May 8, 2017 3:35:46 AM
>>>> To: Maven Users List
>>>> Cc: i...@soebes.de
>>>> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>>>>
>>>> I'm confused by something in Karl's blog as well as the instructions for
>>>> the flatten-maven-plugin and the actual release notes for Maven 3.5.
>>>>
>>>> In all the above, they talk about the ${revision}, ${sha1},
>>>> ${changelist}
>>>> parameters.  But what is so special about those particular parameters?
>>>>
>>> Can
>>>
>>>> I not use any parameter named of my choosing?

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

Hi,

Interesting.  Would something like this be functional then?  It seems to
work, but I don't know if it is working as expected, or by fluke:

com.soebes.examples.j2ee parent
${revision} pom .. 

1.2.1-${buildNumber}
SNAPSHOT



Then at the command line, I can either set the buildNumber in the case of a
build:
mvn installl -DbuildNumber=12345

This works, but I don't know if I am using this as designed/expected.

Thanks,

Eric


On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> Hello,
>
> Only those specific properties are allowed. If I remember correctly the
> reason for it is a mixture between it is not possible to support full
> property resolving in this stage of the model builder and the intention to
> harmonize/restrict to familiarly named usecases.
>
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=
> blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/
> interpolation/AbstractStringBasedModelInterpolator.java;h=
> b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d78a8bd78ff9f0c7
> 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb=
> 181b0215aa1199e152db9d2c08b1a01436547805
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric Benzacar <e...@benzacar.ca>
> Sent: Monday, May 8, 2017 3:35:46 AM
> To: Maven Users List
> Cc: i...@soebes.de
> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>
> I'm confused by something in Karl's blog as well as the instructions for
> the flatten-maven-plugin and the actual release notes for Maven 3.5.
>
> In all the above, they talk about the ${revision}, ${sha1}, ${changelist}
> parameters.  But what is so special about those particular parameters?  Can
> I not use any parameter named of my choosing?
>
> Afterall, the ${revision} value is being set by an environment property, so
> can I not just call it ${buildNumber} instead?
>
> Ex:
>
> com.soebes.examples.j2ee parent artifactId>
> 1.2.1-${buildNumber} pom ..
>  ... SNAPSHOT 
>
>
> Why do I need to use ${revision}?
> https://maven.apache.org/maven-ci-friendly.html specifically mentions the
> above parameters.  Why?
>
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson <jgeorge...@lgc.com>
> wrote:
>
> > Yup :)
> >
> > -Original Message-
> > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > Sent: Thursday, May 4, 2017 4:52 PM
> > To: Justin Georgeson <jgeorge...@lgc.com>; Maven Users List <
> > users@maven.apache.org>; i...@soebes.de
> > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> >
> > External Sender: Use caution with links/attachments.
> >
> >
> >
> > Hi,
> >
> > On 04/05/17 22:52, Justin Georgeson wrote:
> > > Also I believe the partial reactor switches don't work for Tycho
> builds.
> >
> > You mean -pl ..option I suppose?
> >
> > As far as I know Tycho is handling that at the wrong time of the maven
> > build and furthermore handles in this relationship some other things
> wrong
> > which results in not working things like this..
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > >
> > > -Original Message-
> > > From: Robert Patrick [mailto:robert.patr...@oracle.com]
> > > Sent: Thursday, May 4, 2017 3:18 PM
> > > To: Maven Users List <users@maven.apache.org>; i...@soebes.de
> > > Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> > >
> > > External Sender: Use caution with links/attachments.
> > >
> > >
> > >
> > > Hard to train developers to break old habits but thanks... :-)
> > >
> > >
> > >
> > > -Original Message-
> > > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > > Sent: Thursday, May 04, 2017 3:16 PM
> > > To: Robert Patrick; Maven Users List; i...@soebes.de
> > > Subject: Re: Continuous Delivery with Maven now possible?
> > >
> > > Hi Robert,
> > >
> > > Ah now I see the issue.
> > >
> > > If you have a multi module build you should use
> > >
> > > mvn -pl moduleToBuild clean install
> > >
> > > but from root location and don't change into the module directory cause
> > this can't work like this.
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > On 04/05/17 22:08, Robert Patrick wrote:
> > >> Hi Karl,
> > >>
> > &

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

> >> sion]: Failure to find
> >> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
> >> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
> >> local repo sitory, resolution will not be reattempted until the
> >> update interval of repo1 ha s elapsed or updates are forced and
> >> 'parent.relativePath' points at wrong local POM @ line 7, column 13
> >> -> [Help 2] [ERROR] [ERROR] To see the full stack trace of the
> >> errors, re-run Maven with the -e swit ch.
> >> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> >> [ERROR]
> >> [ERROR] For more information about the errors and possible solutions,
> >> please rea d the following articles:
> >> [ERROR] [Help 1]
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_
> >> c
> >> onfluence_display_MAVEN_ProjectBuildin=DwIDaQ=RoP1YumCXCgaWHvlZYR
> >> 8
> >> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0
> >> &
> >> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRo
> >> H
> >> s2ncTiyaZSJWc3AEyEsUQ=
> >> gException
> >> [ERROR] [Help 2]
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_
> >> c
> >> onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR
> >> 8
> >> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0
> >> &
> >> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZr
> >> q
> >> XoHWM-jV5GAbTtEvug-bc=
> >> delException
> >>
> >>
> >> Did I miss something?
> >>
> >> Thanks,
> >> Robert
> >>
> >> -Original Message-
> >> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> >> Sent: Thursday, May 04, 2017 3:02 PM
> >> To: Maven Users List
> >> Subject: Re: Continuous Delivery with Maven now possible?
> >>
> >> Hi Robert,
> >>
> >>
> >> On 04/05/17 21:55, Robert Patrick wrote:
> >>
> >>> With 3.5, you can now use a variable *but* that variable
> >>  > has to be accessible to the POM prior to finding its  > parent so
> >> the only solution is to move the  >  version number outside the POM
> >> hierarchy and into a -D defined
> >>> variable.
> >>
> >> Which is not true. You can define the property inside the pom file if
> you like and can overwrite the version via command line (-Drevision=...).
> >>
> >>
> >>
> >>  > While this works, it seems to have some undesirable  > aspects to
> >> it.  In my opinion, it would be better if  > Maven could find a way
> >> to resolve this issue  > without resorting to -Ds to specify the  >
> >> value of the variable.
> >>  > I am not sure it is possible but I also worry  > about moving the
> >> version number outside the POM...
> >>>
> >>> Maybe Maven should consider a mechanism by which the project version
> number can be defined in a separate location that is:
> >>>
> >>> 1.) Well-known so that all resolution can happen directly by
> >>> interacting with this location directly, without the need to
> >>> traverse the parent hierarchy
> >>> 2.) It is part of the project structure so that it can be managed in
> >>> the project's source control system
> >>> 3.) It cannot be overridden at build time with command-line arguments.
> >>> 4.) Has a mechanism by which to reference it from all the necessary
> >>> locations within the POMs
> >>>
> >>> Maybe something like an optional .mvn/project.version file and a
> variable that cannot be overridden to refer to it?
> >>>
> >>> -Original Message-
> >>> From: Eric Benzacar [mailto:e...@benzacar.ca]
> >>> Sent: Thursday, May 04, 2017 12:53 PM
> >>> To: Maven Users List
> >>> Subject: Re: Continuous Delivery with Maven now possible?
> >>>
> >>> I've read through Karl's blog
> >>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_
> >>> b
> >>> log_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwm
> >>> b
> >>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
> >>> A YSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
> >>> 2017/04/02/maven-pom-files-wi

Re: Continuous Delivery with Maven now possible?

[Eric Benzacar]

Hi,

Thanks for the detailed response.  You have a lot of great points in there,
and most of them I agree with (and partially implement already).  As a
CI/CD server, I'm using Jenkins and constantly trying to find better ways
to do things.


> First if you make a release your release process must create a tag in your
> version control with this state of your source code. Furthermore you should
> bake informations like the revision number or sha1 of your version control
> system into your resulting artifacts (configuration of maven-jar, maven-war
> etc.) and a branch name is also helpful which I always encourage
> independent of the usage of this here. This makes traceability more
> easier...
>

I'm not currently tagging my code in my build (shameful - I know).  Sadly,
I haven't figured out the "best" way to create my tags on my build server
and push them to my central repo, without completely polluting my repo (I
would rather not have thousands of tags in my repo).  I suspect if I only
auto-tag my builds for RCs, it will reduce the amount of pollution.  But in
a way, at the end of the day, I really only care about the tag for the code
that actually makes it to Prod.

I am already injecting my commit id, build date, build user, build engine
into the Manifest of my artifact, although that too is being done through a
bit of a workaround.  I don't know if there is a Jenkins plugin that will
do this automatically, but at the moment, I have my org pom defined such
that these properties are added to the manifests for jars, wars and ears.
And I pass the parameters using -Dscm.commitId= etc at the maven
build.  I don't know if there is a better way to do this, and if there is,
I would love to hear about it.



> So based on some Continuous Delivery setups in theses days the created tag
> is not that essential. It is only essential to create a new artifact very
> fast without some run of versions-plugin or bash/script vodoo to only
> change the version number in all pom files and produce one, two or three
> (release plugin) checkins which only contain information about the changed
> versions in pom file nothing more interesting...So if you are working with
> branches the version numbers in pom files are always a pain cause they
> produce always conflicts
>

Agreed - changing version numbers is constantly a royal pain.  Between
merge conflicts and a nuissance to rebuild each time, I would love to avoid
it, if possible, without losing any of the traceability it provides.



> Furthermore based on the above described scenario the question comes into
> my mind: Is the version control the righ tool/location to answer this
> question? In the meantime I tend to say no. The artifact repository (Nexus
> for example) is the better tool/location to answer this question...but this
> a very controversy thing...
>

Agreed again.  I believe that the sources should also be automatically
generated and delivered to Nexus along with the binary.  Not only does this
allow for traceability, it also helps significantly in the debugging
process.  However, it is critical to know in the source control which
versions (ie: which commits) of a source file made it into which
build/release.


> Furthermore if you think about this statement in consequence this means
> you are not allowed to use any version ranges in none of your pom files
> cause this will result in more complicated problems than only not knowing
> the version number from your version control...
>

True.  I don't currently use version ranges (have not really ever seen the
need for it), so it isn't as much of an issue for me.  But I can understand
your point.



> The separation between the "build pom" and the "consumer pom" which is
> implicitly done by this. This means the "build pom" is checked into version
> control but not the resulting "consumer pom" which is only intended for
> consumers of your artifacts and only being available in the destination
> artifact repository which has been built by a technical process. This is
> the same as we compile a Java class cause we only have as a result the
> compiled class file in our jar file but not the source files...
>

Very valid.  However, I also look at it from another perspective.  I like
to be able to check out code at any commit, and be able to know which
"version" it is.  The easiest way to do that is to have a pom with a
version in it that specifies that at that particular snapshot in time, I
was looking at the entire code for version 1.2.3-SNAPSHOT, or
1.2.5.RELEASE.  Have parameters in the version info loses that clarity.



> You have the pom which contains the properties with the versions parts
> like revision,changelist and sha1 and the resulting pom file which is
> installed into the repository (see also flatten-maven-plugin)...or just
> define the property(ies) via command line...
>

I need to look at the flatten-maven-plugin a little more closely.  Is the
pom.xml and pom.properties that maven embeds into the 

Re: Continuous Delivery with Maven now possible?

[Eric Benzacar]

I've read through Karl's blog (http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
understand the approach, there is still one critical issue that bothers
me.  I think this actually reopens an old thread that circulated on this
list a few months ago, but it related to the Idempotence of a pom file.

>From my perspective/view a pom file should be idempotent.  That is every
single build of a given NON-SNAPSHOT pom file should finish with the same
build.  But by moving a release number or version number outside of the
pom, it eliminates this need.  Furthermore, from a traceability
perspective, my source control can no longer show me precisely version was
being built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but
none the less, the value can be overridden at build time with a completely
different value.  Consequently, I can still not be 100% confident that a
pom delivered a particular version.

I'm still not 100% sure of the best approach going forward, but I'm
thinking that something like the version-plugin being able to manipulate a
revision property that can then be committed as part of the pom would be
the best of both approaches.  In that way, my developers can fix the
version number, but my build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer  wrote:

> How about everybody read their mail?
> (see below)
>
> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden  wrote:
>
> > Hi Dan, Karl & everyone,
> >
> > > See Karl's Blog
> >
> > Link, please?
> >
> […]
>
> > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I have been experimenting with suggestion from Karl [1] with small
> > > multi
> > > > >> module maven project.
>
> […]
>
> > > > >> [1]
> > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > >> t-a-version-in-it/
> >
>