There is no easy answer for this problem if the two projects are completely unrelated, 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, use the versions plugin to update the project B dependency in Project A to a non-snapshot version, and then release project A. One could argue that if A and B need to be built/released together, they are not really Independent projects...
Robert Patrick > On Apr 20, 2016, at 5:07 AM, Hohl, Gerrit <[email protected]> wrote: > > Hello Stephen, > > 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. > > Let' say we have a project A with the following POM (short version just as an > example): > > <project> > <groupId>com.company</groupId> > <artificateId>project-a</artificateId> > <version>1.0-SNAPSHOT</version> > <packaging>pom</packaging> > </project> > > If I build this my CI server will produce an artifact project-a-1.0.123 (123 > is the build number) and put this into the artifact repository. > > Then I have another project B with the following POM: > > <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> > > The resulting artifact will also something like project-b-1.0.234 (234 is the > 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 > environment of the developer. But if I want to build it on the CI server I > have to define a unique version as I don't want that dependencies switch > automatically and builds can't be repeated. > If I put a defined version there I also need that defined version in the > project 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 > downloaded from the artifact repository and not in the source code of project > A which I also have checked-out. > > Regards, > Gerrit > > -----Ursprüngliche Nachricht----- > Von: Stephen Connolly [mailto:[email protected]] > Gesendet: Mittwoch, 20. April 2016 11:47 > An: Maven Users List > Betreff: Re: Maven and Continous Integration / Continous Delivery > > If I were doing this myself here is what I would do: > > 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=false > -DlocalCheckout=true "-DdevelopmentVersion=dev-SNAPSHOT" > "-DreleaseVersion=${BUILD_ID}" "-DpreparationGoals=clean 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) > > That will basically perform a release with the appropriate commits. > > Then you do the rest of your downstream tests on the release artifacts. > > If anything fails then I would drop the staging repo and nobody is any the > wiser > > If it's all good and you are all set to push to production you now have a > choice: > > * Do you want a human intervention or auto-deploy? > > If a human intervention - put an input step in your pipeline to get > confirmation to continue > > Now we need to do the deployment for real. > > 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. > > > > > Now here are some of the tricks that we do with this approach: > > - 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) > > 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 either 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 if > something went wrong, so nobody has to worry about broken artifacts. > > > 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 > > > >> On 20 April 2016 at 10:07, Hohl, Gerrit <[email protected]> wrote: >> >> Hello everyone, :-) >> >> >> >> 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. >> >> >> >> Anyone solved that problem? >> >> >> >> Regards, >> >> Gerrit > ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖ֖âW6W'2×Vç7V'67&–&TÖfVâæ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âW6W'2Ö†VÇÖfVâæ6†Ræ÷&pÐ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
