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: <groupId>com.benze</groupId> <artifactId>parent</artifactId> <version>${revision}${sha1}${changelist}</version> <packaging>pom</packaging> <properties> <revision>1.3.1</revision> <changelist>-SNAPSHOT</changelist> <sha1/> </properties> but in my child poms, I'm not sure how to refer to the parent: <artifactId>webapp</artifactId> <packaging>war</packaging> <parent> <groupId>com.benze</groupId> <artifactId>parent</artifactId> <version> ??????? </version> <relativePath>../superpom</relativePath> </parent> 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 <dant...@gmail.com> 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 <dant...@gmail.com> 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 <version>${revision}</version> > > > > [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 > > >