Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
From: Robert Patrick <robert.patrick@oracle.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: AW: Maven and Continous Integration / Continous Delivery
Message-Id: <0A95242C-A96E-400A-BED6-82A08E909487@oracle.com>
Date: Wed, 20 Apr 2016 06:33:38 -0500
References: <3B7A7BDFFD286F49A19A5B35D26E08FB01BB3B0E@srvmail2.aurenz.local>
 <CA+nPnMzpi1aRHzeSJecusu1e5ABkscK6fricPHt7xXMwEOJc2w@mail.gmail.com>
 <3B7A7BDFFD286F49A19A5B35D26E08FB01BB3B23@srvmail2.aurenz.local>
In-Reply-To: <3B7A7BDFFD286F49A19A5B35D26E08FB01BB3B23@srvmail2.aurenz.local>
To: Maven Users List <users@maven.apache.org>

There is no easy answer for this problem if the two projects are completely u=
nrelated, build-wise.  Stephen is suggesting the easiest way to handle this,=
 which sort of implies that they are built together via a multi-module POM. =
 Without this, you would have to use the release plugin to build project B, u=
se the versions plugin to update the project B dependency in Project A to a n=
on-snapshot version, and then release project A.  One could argue that if A a=
nd B need to be built/released together, they are not really Independent pro=
jects...

Robert Patrick

> On Apr 20, 2016, at 5:07 AM, Hohl, Gerrit <g.hohl@aurenz.de> wrote:
>=20
> Hello Stephen,
>=20
> thank you very much for your fast and long answer.
> Somehow that seems very complicated.
> And unfortunately it also doesn't answer some of my questions.
>=20
> Let' say we have a project A with the following POM (short version just as=
 an example):
>=20
> <project>
>    <groupId>com.company</groupId>
>    <artificateId>project-a</artificateId>
>    <version>1.0-SNAPSHOT</version>
>    <packaging>pom</packaging>
> </project>
>=20
> If I build this my CI server will produce an artifact project-a-1.0.123 (1=
23 is the build number) and put this into the artifact repository.
>=20
> Then I have another project B with the following POM:
>=20
> <project>
>    <groupId>com.company</groupId>
>    <artificateId>project-b</artificateId>
>    <version>1.0-SNAPSHOT</version>
>    <packaging>pom</packaging>
>    <dependencyManagement>
>        <dependencies>
>            <groupId>com.company</groupId>
>            <artificateId>project-a</artificateId>
>            <version>???</version>
>        </dependencies>
>    </dependencyManagement>
>    <dependencies>
>        <dependency>
>            <groupId>com.company</groupId>
>            <artificateId>project-a</artificateId>
>        </dependency>
>    </dependencies>
> </project>
>=20
> The resulting artifact will also something like project-b-1.0.234 (234 is t=
he build number) and put into the artifact repository.
> But I will have the problem with the "???" at the version tag of project A=
. I can put there also "1.0-SNAPSHOT" which maybe would be okay for the envi=
ronment of the developer. But if I want to build it on the CI server I have t=
o define a unique version as I don't want that dependencies switch automatic=
ally and builds can't be repeated.
> If I put a defined version there I also need that defined version in the p=
roject A. Otherwise I will get problems in the IDE as it maybe don't realize=
 that project B uses the project A which I currently have checked-out. Means=
 if I do debugging I will always end up in the sources of the artifact downl=
oaded from the artifact repository and not in the source code of project A w=
hich I also have checked-out.
>=20
> Regards,
> Gerrit
>=20
> -----Urspr=C3=83=C2=BCngliche Nachricht-----
> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]=20
> Gesendet: Mittwoch, 20. April 2016 11:47
> An: Maven Users List
> Betreff: Re: Maven and Continous Integration / Continous Delivery
>=20
> If I were doing this myself here is what I would do:
>=20
> I would use a MRM that has staging support and setup a Jenkins Pipeline
> that starts by doing
> `mvn release:prepare release:perform -B -DpushChanges=3Dfalse
> -DlocalCheckout=3Dtrue "-DdevelopmentVersion=3Ddev-SNAPSHOT"
> "-DreleaseVersion=3D${BUILD_ID}" "-DpreparationGoals=3Dclean validate"` it=

> should also capture the GIT repo state so that the tag and release commits=

> can be resurrected on a different node (because I'd be using e.g. docker
> based build slaves that are ephemeral)
>=20
> That will basically perform a release with the appropriate commits.
>=20
> Then you do the rest of your downstream tests on the release artifacts.
>=20
> If anything fails then I would drop the staging repo and nobody is any the=

> wiser
>=20
> If it's all good and you are all set to push to production you now have a
> choice:
>=20
> * Do you want a human intervention or auto-deploy?
>=20
> If a human intervention - put an input step in your pipeline to get
> confirmation to continue
>=20
> Now we need to do the deployment for real.
>=20
> So we grab a node, restore the git repo and now we can push the tag
> upstream, release the staging repo and push the released artifacts into
> production.
>=20
>=20
>=20
>=20
> Now here are some of the tricks that we do with this approach:
>=20
>   - We do not push the release commits back to the git server, we only
>   push the tag (and only on a successful build that is being deployed into=

>   production - a tag for *every* build is not necessary, alternatively you=

>   could delete tags that are not needed any more and push every tag)
>=20
>   This is important as there could be intervening commits in master that
>   modify the pom.xml and as a result the merge may not be possible.
>   - We leave the pom with a dummy -SNAPSHOT version for developers, thus
>   they never have to worry about merge conflicts from master due to the
>   release plugin bumping version numbers
>   - We specify the release version using the build id (or some other
>   component controlled by the CI server... we want something that is eithe=
r a
>   timestamp or a strictly increasing function)
>   - We skip the preparation checks. Because nobody will ever see the
>   borked tag, we only need to test once and we will throw away everything i=
f
>   something went wrong, so nobody has to worry about broken artifacts.
>=20
>=20
> That is how I would handle it. Given a bit more time I could probably make=

> it an even nicer flow (e.g. we could push the tags always, but into a
> different git repo and then we can pull those tags over to the developer
> repo for promotion to deploy
>=20
>=20
>=20
>> On 20 April 2016 at 10:07, Hohl, Gerrit <g.hohl@aurenz.de> wrote:
>>=20
>> Hello everyone, :-)
>>=20
>>=20
>>=20
>> I'm currently sitting on the book "Continuous Delivery" written by Jez
>> Humble and David Farley.
>>=20
>> They write that each build is a potential release candidate. And each
>> build should be triggered by the check-in into the SCM.
>>=20
>> So far, so good. But how do I realize that in Maven?
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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
>>=20
>>=20
>> Anyone solved that problem?
>>=20
>>=20
>>=20
>> Regards,
>>=20
>> Gerrit
> =C3=90=C2=A2=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=
=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=
=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=
=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=
=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=
=92=C3=92=C3=92=C3=92=C3=92=C3=92=C3=90=C3=90=C2=A5F=C3=B2=07V=C3=A77V'67&=E2=
=80=93&R=C3=82=06R=C3=96=C3=96=16=E2=80=93=C3=83=C2=A2=07W6W'2=C3=97V=C3=A77=
V'67&=E2=80=93&T=06=C3=96=17fV=C3=A2=C3=A6=17=06=166=E2=80=A0R=C3=A6=C3=B7&p=
=C3=90=C2=A4f=C3=B7"=06=16FF=E2=80=94F=E2=80=93=C3=B6=C3=A6=16=C3=82=066=C3=B6=
=C3=96=C3=96=16=C3=A6G2=C3=82=06R=C3=96=C3=96=16=E2=80=93=C3=83=C2=A2=07W6W'=
2=C3=96=E2=80=A0V=C3=87=04=06=C3=96=17fV=C3=A2=C3=A6=17=06=166=E2=80=A0R=C3=A6=
=C3=B7&p=C3=90


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org