Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01D19AE4.12E370FA"
Subject: Maven and Continous Integration / Continous Delivery
Date: Wed, 20 Apr 2016 11:07:32 +0200
Message-ID: <3B7A7BDFFD286F49A19A5B35D26E08FB01BB3B0E@srvmail2.aurenz.local>
Thread-Topic: Maven and Continous Integration / Continous Delivery
Thread-Index: AdGa4rJA5nn6CErUQ+G3xUotNlv74g==
From: "Hohl, Gerrit" <g.hohl@aurenz.de>
To: <users@maven.apache.org>

------_=_NextPart_001_01D19AE4.12E370FA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello everyone, :-)

=20

I'm currently sitting on the book "Continuous Delivery" written by Jez
Humble and David Farley.

They write that each build is a potential release candidate. And each
build should be triggered by the check-in into the SCM.

So far, so good. But how do I realize that in Maven?

Up until now the version number in our Maven projects and modules have
been static. If it had to be changed the developer had to perform that
step.

But if the CI server performs the build as well as putting the result
into the repository (in our case Nexus), the resulting artifacts have to
include the build number in some way. Otherwise I overwrite the same
artifact other and other again until a developer changes the version in
the POM file. Depending projects then will see only the last version of
the artifact and builds won't be repeatable (means the functionality of
the artifact changes without anyone noticing it).

One way would be to modify the POM between the check-out from the SCM
and the Maven build process and writing the build number into it.

But then I will have the problem in the IDE that it don't understand
that the current version I've checked-out is the version I have referred
on in another project I've checked-out.

If the CI server checks-in the changed POM file afterwards it will
trigger the next build. Also it will cause problems if the POM was
changed in the SCM in the meantime as the CI maybe can't merge it.

=20

Anyone solved that problem?

=20

Regards,

Gerrit

=20


------_=_NextPart_001_01D19AE4.12E370FA--