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 <dant...@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 <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:
> >
> > <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
> > > >
> > >
> >
>
