Hello Stephen, I forgot that I not only have the problem in the IDE about debugging and viewing the code of project A from project B, I also can't do a local build which depends on the right version.
I also have to add that the viewing even works for Eclipse using the Eclipse-Maven-Plugin as it recognizes only the name of the artifact when looking for an open project in the IDE and doesn't care for the version. But that is not really a feature as you will get problems if you want to use / debug with a version from your artifact repository which is different from the one which you have checked-out in your IDE. Regards, Gerrit -----Ursprüngliche Nachricht----- Von: Hohl, Gerrit [mailto:[email protected]] Gesendet: Mittwoch, 20. April 2016 12:08 An: Maven Users List Betreff: AW: Maven and Continous Integration / Continous Delivery 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 > > > > ----------------------- ssi,-i [email protected] rdtn mn,-i e-lmeac.g
