maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Benzacar <e...@benzacar.ca>
Subject Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Date Wed, 08 Nov 2017 22:30:59 GMT
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 <dantran@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 <eric@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 <dantran@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 <dantran@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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message