You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Eric Benzacar <er...@benzacar.ca> on 2017/07/27 03:37:28 UTC
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
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 <da...@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 <da...@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
> >
>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Eric B <eb...@gmail.com>.
Thanks. The extension is precisely what I'm looking for.
Eric
On Nov 9, 2017 3:47 AM, "Pascal" <pa...@gmail.com> wrote:
> > interpolation of these special parameters must happen prior to the
> execution of any plugins
>
> That's exactly correct. It's why I built
> https://github.com/pascalgn/properties-maven-extension which is
> implemented
> as an extension and runs before any plugins will be executed.
> Maybe it can help you.
>
> 2017-11-09 3:11 GMT+01:00 Eric B <eb...@gmail.com>:
>
> > I tried removing the empty sha1 declaration as well but that didn't work
> > either.
> >
> > I'm guessing it's due to sequencing - that the interpolation of these
> > special parameters must happen prior to the execution of any plugins, but
> > would love confirmation of that. Additionally would love to know if
> there
> > is a workaround for this situation.
> >
> > Thanks
> >
> > Eric
> >
> > On Nov 8, 2017 6:35 PM, "Laird Nelson" <lj...@gmail.com> wrote:
> >
> > > On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar <er...@benzacar.ca> wrote:
> > >
> > > > 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.
> > > >
> > >
> > > [snip]
> > >
> > > A snippet of my pom:
> > > >
> > > > <project>
> > > > <artifactId>test</artifactId>
> > > > <groupId>org.project</groupId>
> > > > <version>${revision}${sha1}${changelist}</version>
> > > > <properties>
> > > > <sha1></sha1>
> > > >
> > >
> > > Blind guess: since the buildnumber-maven-plugin is going to set
> > properties
> > > using internal machinery, and you've told it the one to set should be
> > named
> > > sha1, is it possible that this empty property of the same name is
> > shadowing
> > > the one set by the plugin, or that perhaps the plugin won't set it
> since
> > > it's already (effectively) specified?
> > >
> > > Best,
> > > Laird
> > > --
> > > https://about.me/lairdnelson
> > >
> >
>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Pascal <pa...@gmail.com>.
> interpolation of these special parameters must happen prior to the
execution of any plugins
That's exactly correct. It's why I built
https://github.com/pascalgn/properties-maven-extension which is implemented
as an extension and runs before any plugins will be executed.
Maybe it can help you.
2017-11-09 3:11 GMT+01:00 Eric B <eb...@gmail.com>:
> I tried removing the empty sha1 declaration as well but that didn't work
> either.
>
> I'm guessing it's due to sequencing - that the interpolation of these
> special parameters must happen prior to the execution of any plugins, but
> would love confirmation of that. Additionally would love to know if there
> is a workaround for this situation.
>
> Thanks
>
> Eric
>
> On Nov 8, 2017 6:35 PM, "Laird Nelson" <lj...@gmail.com> wrote:
>
> > On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar <er...@benzacar.ca> wrote:
> >
> > > 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.
> > >
> >
> > [snip]
> >
> > A snippet of my pom:
> > >
> > > <project>
> > > <artifactId>test</artifactId>
> > > <groupId>org.project</groupId>
> > > <version>${revision}${sha1}${changelist}</version>
> > > <properties>
> > > <sha1></sha1>
> > >
> >
> > Blind guess: since the buildnumber-maven-plugin is going to set
> properties
> > using internal machinery, and you've told it the one to set should be
> named
> > sha1, is it possible that this empty property of the same name is
> shadowing
> > the one set by the plugin, or that perhaps the plugin won't set it since
> > it's already (effectively) specified?
> >
> > Best,
> > Laird
> > --
> > https://about.me/lairdnelson
> >
>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Eric B <eb...@gmail.com>.
I tried removing the empty sha1 declaration as well but that didn't work
either.
I'm guessing it's due to sequencing - that the interpolation of these
special parameters must happen prior to the execution of any plugins, but
would love confirmation of that. Additionally would love to know if there
is a workaround for this situation.
Thanks
Eric
On Nov 8, 2017 6:35 PM, "Laird Nelson" <lj...@gmail.com> wrote:
> On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar <er...@benzacar.ca> wrote:
>
> > 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.
> >
>
> [snip]
>
> A snippet of my pom:
> >
> > <project>
> > <artifactId>test</artifactId>
> > <groupId>org.project</groupId>
> > <version>${revision}${sha1}${changelist}</version>
> > <properties>
> > <sha1></sha1>
> >
>
> Blind guess: since the buildnumber-maven-plugin is going to set properties
> using internal machinery, and you've told it the one to set should be named
> sha1, is it possible that this empty property of the same name is shadowing
> the one set by the plugin, or that perhaps the plugin won't set it since
> it's already (effectively) specified?
>
> Best,
> Laird
> --
> https://about.me/lairdnelson
>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Laird Nelson <lj...@gmail.com>.
On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar <er...@benzacar.ca> wrote:
> 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.
>
[snip]
A snippet of my pom:
>
> <project>
> <artifactId>test</artifactId>
> <groupId>org.project</groupId>
> <version>${revision}${sha1}${changelist}</version>
> <properties>
> <sha1></sha1>
>
Blind guess: since the buildnumber-maven-plugin is going to set properties
using internal machinery, and you've told it the one to set should be named
sha1, is it possible that this empty property of the same name is shadowing
the one set by the plugin, or that perhaps the plugin won't set it since
it's already (effectively) specified?
Best,
Laird
--
https://about.me/lairdnelson
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Dan Tran <da...@gmail.com>.
I don't think I can help much since I don't use sha1 for revision prop.
For my case, I run buildnumber:create-metadata top level only
(<inherited>true</inherited>) to track SCM info per build and user
Jenkins env.BUILD_NUMBER for CD version
-Dan
On Wed, Nov 8, 2017 at 2:30 PM, Eric Benzacar <er...@benzacar.ca> wrote:
> 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 <version> 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 <version>? Is
> the only option to pass the ${sha1} value on command line?
>
>
> A snippet of my pom:
>
> <project>
> <artifactId>test</artifactId>
> <groupId>org.project</groupId>
> <version>${revision}${sha1}${changelist}</version>
> <properties>
> <sha1></sha1>
> <revision>5.0.0</revision>
> <changelist></changelist>
> </properties>
>
> <!-- OMITTED FOR BREVITY -->
> <build>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>buildnumber-maven-plugin</artifactId>
> <version>1.4</version>
> <executions>
> <execution>
> <id>generate-sha1</id>
> <phase>validate</phase>
> <goals>
> <goal>create</goal>
> </goals>
> <configuration>
> <!-- specify the special property name for the commit id -->
> <buildNumberPropertyName>sha1</buildNumberPropertyName>
> <!-- prefix the commitId with a hyphen for the version -->
> <format>-{0}</format>
> <items>
> <item>scmVersion</item>
> </items>
> <shortRevisionLength>8</shortRevisionLength>
> </configuration>
> </execution>
> <execution>
> <id>generate-metadata</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>create-metadata</goal>
> </goals>
> <configuration>
> <version>${revision}${sha1}${changelist}</version>
> <addOutputDirectoryToResources>true</addOutputDirectoryToResources>
> <attach>true</attach>
> <outputName>META-INF/build.properties</outputName>
> </configuration>
> </execution>
> </executions>
> <configuration>
> <revisionOnScmFailure>no.scm.config.in.pom</revisionOnScmFailure>
> <!--make it available for jar/war classpath resource -->
> </configuration>
> </plugin>
> <!-- OMITTED FOR BREVITY -->
> </plugins>
> </build>
> </project>
>
>
> Thanks!
>
> Eric
>
>
> On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran <da...@gmail.com> wrote:
>
> > Hi Eric
> >
> >
> > i am using the follow at top level parent
> >
> > <version>${revision}</version>
> >
> > <properties>
> > <revision>x.y.x-SNAPSHOT</revision>
> > </properties>
> >
> > In child pom
> >
> > <parent>
> > ...
> > <version>${revision}</version>
> > </parent>
> >
> >
> > 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 <er...@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:
> > >
> > > <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 <da...@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 <da...@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
> > > > >
> > > >
> > >
> >
>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Eric Benzacar <er...@benzacar.ca>.
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 <version> 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 <version>? Is
the only option to pass the ${sha1} value on command line?
A snippet of my pom:
<project>
<artifactId>test</artifactId>
<groupId>org.project</groupId>
<version>${revision}${sha1}${changelist}</version>
<properties>
<sha1></sha1>
<revision>5.0.0</revision>
<changelist></changelist>
</properties>
<!-- OMITTED FOR BREVITY -->
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>generate-sha1</id>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<!-- specify the special property name for the commit id -->
<buildNumberPropertyName>sha1</buildNumberPropertyName>
<!-- prefix the commitId with a hyphen for the version -->
<format>-{0}</format>
<items>
<item>scmVersion</item>
</items>
<shortRevisionLength>8</shortRevisionLength>
</configuration>
</execution>
<execution>
<id>generate-metadata</id>
<phase>generate-resources</phase>
<goals>
<goal>create-metadata</goal>
</goals>
<configuration>
<version>${revision}${sha1}${changelist}</version>
<addOutputDirectoryToResources>true</addOutputDirectoryToResources>
<attach>true</attach>
<outputName>META-INF/build.properties</outputName>
</configuration>
</execution>
</executions>
<configuration>
<revisionOnScmFailure>no.scm.config.in.pom</revisionOnScmFailure>
<!--make it available for jar/war classpath resource -->
</configuration>
</plugin>
<!-- OMITTED FOR BREVITY -->
</plugins>
</build>
</project>
Thanks!
Eric
On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran <da...@gmail.com> wrote:
> Hi Eric
>
>
> i am using the follow at top level parent
>
> <version>${revision}</version>
>
> <properties>
> <revision>x.y.x-SNAPSHOT</revision>
> </properties>
>
> In child pom
>
> <parent>
> ...
> <version>${revision}</version>
> </parent>
>
>
> 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 <er...@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:
> >
> > <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 <da...@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 <da...@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
> > > >
> > >
> >
>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Posted by Dan Tran <da...@gmail.com>.
Hi Eric
i am using the follow at top level parent
<version>${revision}</version>
<properties>
<revision>x.y.x-SNAPSHOT</revision>
</properties>
In child pom
<parent>
...
<version>${revision}</version>
</parent>
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 <er...@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:
>
> <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 <da...@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 <da...@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
> > >
> >
>