Re: Maven and Continous Integration / Continous Delivery
you can tag each build using JFrog Artifactory, so deletions are manageable -D On Thu, Apr 21, 2016 at 9:19 PM, Laird Nelson wrote: > On Thu, Apr 21, 2016 at 7:31 PM Robert Patrick > wrote: > > > I can tell you first-hand that deleting thousands of old build versions > IS > > a nightmare. That's why we are using SNAPSHOTs and only switch to > version > > numbers for end of sprint builds. > > > > +1 > > Best, > Laird >
Re: Maven and Continous Integration / Continous Delivery
On Thu, Apr 21, 2016 at 7:31 PM Robert Patrick wrote: > I can tell you first-hand that deleting thousands of old build versions IS > a nightmare. That's why we are using SNAPSHOTs and only switch to version > numbers for end of sprint builds. > +1 Best, Laird
RE: Maven and Continous Integration / Continous Delivery
I just glanced through the current article but I suspect that this doesn’t work with POMs that have parent references where the version is the same as the project (e.g., the parent is the aggregate POM in the directory above each module). In my current projects, I would only have a single version number in the top-level POM if it weren't for the parent references in the submodule POMs. As far as I can tell, Maven will not accept a variable for a parent POM reference version number. Unless this issue is resolved, it will be hard to use this technique for any complex projects. I can tell you first-hand that deleting thousands of old build versions IS a nightmare. That's why we are using SNAPSHOTs and only switch to version numbers for end of sprint builds. -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, April 21, 2016 9:17 PM To: Maven Users List Subject: Re: Maven and Continous Integration / Continous Delivery the big issue with that technique is that the pom deployed to maven repo, its version is the real version, will be maintaining nightmare -D On Wed, Apr 20, 2016 at 2:17 AM, Francois-Xavier Bonnet < francois-xavier.bon...@centraliens.net> wrote: > Maybe this article could help: > https://axelfontaine.com/blog/dead-burried.html > > 2016-04-20 11:07 GMT+02:00 Hohl, Gerrit : > > > 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 > > > > > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven & Continuous Delivery
does it upload the pom with its version fully translated? Thanks -D On Thu, Apr 21, 2016 at 6:40 PM, Benson Margulies wrote: > On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran wrote: > > Hi Benson > > > > Sounds promissing > > > > does it support jenkins env BUILD_NUM? > > I doubt it. I dislike Jenkins and avoid having anything to do with it. > Feel free to make a PR. > > > does it push the actual version to maven repo at install/deploy time? > > if you run mvn deploy, your artifacts will be deployed. > > > > > > Thanks > > > > -Dan > > > > On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies > > > wrote: > > > >> https://github.com/basis-technology-corp/auto-version-maven-extension > >> > >> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen > >> wrote: > >> >> > >> >> Jason van Zyl also mentioned he was working on CD solution for Maven > >> last > >> >> year, not sure what the progress on this front. > >> > > >> > > >> > Yes, I've been curious about the progress too. It's very needed and > so > >> > promising. > >> > > >> > > >> > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran wrote: > >> > > >> >> Thanks Stephen. > >> >> > >> >> I was excited for a short moment but hitting the reality where I may > >> have > >> >> to deal with hundreds of dev and qa over the confusion of the hidden > >> >> version. Especially, when they have to rebuild a subset of the > product. > >> It > >> >> just not working > >> >> > >> >> Jason van Zyl also mentioned he was working on CD solution for Maven > >> last > >> >> year, not sure what the progress on this front. > >> >> > >> >> -Dan > >> >> > >> >> > >> >> > >> >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly < > >> >> stephen.alan.conno...@gmail.com> wrote: > >> >> > >> >> > I share your concern. We could fix the concern if we created the > >> >> > transformed pom on disk so that things like GPG signatures were > >> generated > >> >> > correctly, but AIUI the issue there was that the pom could not be > put > >> in > >> >> > target as that would break relative paths. > >> >> > > >> >> > I suspect this is also related to the issue of dependency reduced > poms > >> >> for > >> >> > shade... or any feature where the pom to be used downstream in the > >> >> reactor > >> >> > needs to differ from the pom on disk. > >> >> > > >> >> > For me, having been burned by not building the effective pom from a > >> clean > >> >> > checkout I actually favour the use of the release plugin, typically > >> for > >> >> CD > >> >> > I just have the next development version the same as the current > and > >> if > >> >> you > >> >> > tune your preparationGoals then you can just have one compile test > >> >> cycle... > >> >> > > >> >> > But the fight of that blog is a bit like the idiotic quest people > >> have to > >> >> > run the tests once only with code coverage as part of the single > test > >> >> > execution... until you have been burned by the code coverage > affecting > >> >> > effective bytecode and preventing the synchronization bug from > being > >> >> caught > >> >> > by your tests (plus other test invalidating behaviours I have seen) > >> you > >> >> > will run around trying to get rid of the second test execution... > >> >> > > >> >> > Those who do not understand why we do things will be condemned to > >> repeat > >> >> > our mistakes that made us do things that way. > >> >> > > >> >> > Having said that, it is a good pressure to have people pushing the > >> "why > >> >> do > >> >> > we need to do it this way" envelope... perhaps it is time that we > >> need to > >> >> > ensure that the release plugin has a page outlining our rational > for > >> the > >> >> > current default behaviour, common ways to tweak it and stressing > that > >> we > >> >> > have provided a framework for releasing and others are welcome to > >> reuse > >> >> the > >> >> > framework in their own release plugins > >> >> > > >> >> > On 16 April 2016 at 06:01, Dan Tran wrote: > >> >> > > >> >> > > Hi, > >> >> > > > >> >> > > Anyone practicing CD according to this blog? > >> >> > > https://axelfontaine.com/blog/dead-burried.html > >> >> > > > >> >> > > I can build locally, but have a huge concern on the pom deployed > at > >> >> maven > >> >> > > repo since it does NOT have the exact version > >> >> > > > >> >> > > If you do, please share your experience. Any hick up when you > >> introduce > >> >> > > this new practice? > >> >> > > > >> >> > > For our case, we have about 200 modules project and about 100 > dev + > >> qa > >> >> > > > >> >> > > Thanks > >> >> > > > >> >> > > -Dan > >> >> > > > >> >> > > >> >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Re: Maven and Continous Integration / Continous Delivery
the big issue with that technique is that the pom deployed to maven repo, its version is the real version, will be maintaining nightmare -D On Wed, Apr 20, 2016 at 2:17 AM, Francois-Xavier Bonnet < francois-xavier.bon...@centraliens.net> wrote: > Maybe this article could help: > https://axelfontaine.com/blog/dead-burried.html > > 2016-04-20 11:07 GMT+02:00 Hohl, Gerrit : > > > 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 > > > > > > > > >
Re: Maven & Continuous Delivery
On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran wrote: > Hi Benson > > Sounds promissing > > does it support jenkins env BUILD_NUM? I doubt it. I dislike Jenkins and avoid having anything to do with it. Feel free to make a PR. > does it push the actual version to maven repo at install/deploy time? if you run mvn deploy, your artifacts will be deployed. > > Thanks > > -Dan > > On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies > wrote: > >> https://github.com/basis-technology-corp/auto-version-maven-extension >> >> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen >> wrote: >> >> >> >> Jason van Zyl also mentioned he was working on CD solution for Maven >> last >> >> year, not sure what the progress on this front. >> > >> > >> > Yes, I've been curious about the progress too. It's very needed and so >> > promising. >> > >> > >> > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran wrote: >> > >> >> Thanks Stephen. >> >> >> >> I was excited for a short moment but hitting the reality where I may >> have >> >> to deal with hundreds of dev and qa over the confusion of the hidden >> >> version. Especially, when they have to rebuild a subset of the product. >> It >> >> just not working >> >> >> >> Jason van Zyl also mentioned he was working on CD solution for Maven >> last >> >> year, not sure what the progress on this front. >> >> >> >> -Dan >> >> >> >> >> >> >> >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly < >> >> stephen.alan.conno...@gmail.com> wrote: >> >> >> >> > I share your concern. We could fix the concern if we created the >> >> > transformed pom on disk so that things like GPG signatures were >> generated >> >> > correctly, but AIUI the issue there was that the pom could not be put >> in >> >> > target as that would break relative paths. >> >> > >> >> > I suspect this is also related to the issue of dependency reduced poms >> >> for >> >> > shade... or any feature where the pom to be used downstream in the >> >> reactor >> >> > needs to differ from the pom on disk. >> >> > >> >> > For me, having been burned by not building the effective pom from a >> clean >> >> > checkout I actually favour the use of the release plugin, typically >> for >> >> CD >> >> > I just have the next development version the same as the current and >> if >> >> you >> >> > tune your preparationGoals then you can just have one compile test >> >> cycle... >> >> > >> >> > But the fight of that blog is a bit like the idiotic quest people >> have to >> >> > run the tests once only with code coverage as part of the single test >> >> > execution... until you have been burned by the code coverage affecting >> >> > effective bytecode and preventing the synchronization bug from being >> >> caught >> >> > by your tests (plus other test invalidating behaviours I have seen) >> you >> >> > will run around trying to get rid of the second test execution... >> >> > >> >> > Those who do not understand why we do things will be condemned to >> repeat >> >> > our mistakes that made us do things that way. >> >> > >> >> > Having said that, it is a good pressure to have people pushing the >> "why >> >> do >> >> > we need to do it this way" envelope... perhaps it is time that we >> need to >> >> > ensure that the release plugin has a page outlining our rational for >> the >> >> > current default behaviour, common ways to tweak it and stressing that >> we >> >> > have provided a framework for releasing and others are welcome to >> reuse >> >> the >> >> > framework in their own release plugins >> >> > >> >> > On 16 April 2016 at 06:01, Dan Tran wrote: >> >> > >> >> > > Hi, >> >> > > >> >> > > Anyone practicing CD according to this blog? >> >> > > https://axelfontaine.com/blog/dead-burried.html >> >> > > >> >> > > I can build locally, but have a huge concern on the pom deployed at >> >> maven >> >> > > repo since it does NOT have the exact version >> >> > > >> >> > > If you do, please share your experience. Any hick up when you >> introduce >> >> > > this new practice? >> >> > > >> >> > > For our case, we have about 200 modules project and about 100 dev + >> qa >> >> > > >> >> > > Thanks >> >> > > >> >> > > -Dan >> >> > > >> >> > >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why did the Maven Site Plugin 3.4.1 vanished
Hi, 3.4.1? This version never existed http://svn.apache.org/viewvc/maven/plugins/tags/ Didn't you look for 3.5.1? Regards, Hervé Le jeudi 21 avril 2016 23:52:25 Oliver B. Fischer a écrit : > Hi, > > I just recognized that version 3.4.1 of the Maven Site Plugin vanished > from Maven Central. Does someone how why? > > Oliver - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and Continous Integration / Continous Delivery
Maybe this article could help: https://axelfontaine.com/blog/dead-burried.html 2016-04-20 11:07 GMT+02:00 Hohl, Gerrit : > 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 > > > >
Why did the Maven Site Plugin 3.4.1 vanished
Hi, I just recognized that version 3.4.1 of the Maven Site Plugin vanished from Maven Central. Does someone how why? Oliver -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net S oliver.b.fischer J oliver.b.fisc...@jabber.org X http://xing.to/obf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven & Continuous Delivery
Hi Benson Sounds promissing does it support jenkins env BUILD_NUM? does it push the actual version to maven repo at install/deploy time? Thanks -Dan On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies wrote: > https://github.com/basis-technology-corp/auto-version-maven-extension > > On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen > wrote: > >> > >> Jason van Zyl also mentioned he was working on CD solution for Maven > last > >> year, not sure what the progress on this front. > > > > > > Yes, I've been curious about the progress too. It's very needed and so > > promising. > > > > > > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran wrote: > > > >> Thanks Stephen. > >> > >> I was excited for a short moment but hitting the reality where I may > have > >> to deal with hundreds of dev and qa over the confusion of the hidden > >> version. Especially, when they have to rebuild a subset of the product. > It > >> just not working > >> > >> Jason van Zyl also mentioned he was working on CD solution for Maven > last > >> year, not sure what the progress on this front. > >> > >> -Dan > >> > >> > >> > >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly < > >> stephen.alan.conno...@gmail.com> wrote: > >> > >> > I share your concern. We could fix the concern if we created the > >> > transformed pom on disk so that things like GPG signatures were > generated > >> > correctly, but AIUI the issue there was that the pom could not be put > in > >> > target as that would break relative paths. > >> > > >> > I suspect this is also related to the issue of dependency reduced poms > >> for > >> > shade... or any feature where the pom to be used downstream in the > >> reactor > >> > needs to differ from the pom on disk. > >> > > >> > For me, having been burned by not building the effective pom from a > clean > >> > checkout I actually favour the use of the release plugin, typically > for > >> CD > >> > I just have the next development version the same as the current and > if > >> you > >> > tune your preparationGoals then you can just have one compile test > >> cycle... > >> > > >> > But the fight of that blog is a bit like the idiotic quest people > have to > >> > run the tests once only with code coverage as part of the single test > >> > execution... until you have been burned by the code coverage affecting > >> > effective bytecode and preventing the synchronization bug from being > >> caught > >> > by your tests (plus other test invalidating behaviours I have seen) > you > >> > will run around trying to get rid of the second test execution... > >> > > >> > Those who do not understand why we do things will be condemned to > repeat > >> > our mistakes that made us do things that way. > >> > > >> > Having said that, it is a good pressure to have people pushing the > "why > >> do > >> > we need to do it this way" envelope... perhaps it is time that we > need to > >> > ensure that the release plugin has a page outlining our rational for > the > >> > current default behaviour, common ways to tweak it and stressing that > we > >> > have provided a framework for releasing and others are welcome to > reuse > >> the > >> > framework in their own release plugins > >> > > >> > On 16 April 2016 at 06:01, Dan Tran wrote: > >> > > >> > > Hi, > >> > > > >> > > Anyone practicing CD according to this blog? > >> > > https://axelfontaine.com/blog/dead-burried.html > >> > > > >> > > I can build locally, but have a huge concern on the pom deployed at > >> maven > >> > > repo since it does NOT have the exact version > >> > > > >> > > If you do, please share your experience. Any hick up when you > introduce > >> > > this new practice? > >> > > > >> > > For our case, we have about 200 modules project and about 100 dev + > qa > >> > > > >> > > Thanks > >> > > > >> > > -Dan > >> > > > >> > > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven & Continuous Delivery
https://github.com/basis-technology-corp/auto-version-maven-extension On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen wrote: >> >> Jason van Zyl also mentioned he was working on CD solution for Maven last >> year, not sure what the progress on this front. > > > Yes, I've been curious about the progress too. It's very needed and so > promising. > > > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran wrote: > >> Thanks Stephen. >> >> I was excited for a short moment but hitting the reality where I may have >> to deal with hundreds of dev and qa over the confusion of the hidden >> version. Especially, when they have to rebuild a subset of the product. It >> just not working >> >> Jason van Zyl also mentioned he was working on CD solution for Maven last >> year, not sure what the progress on this front. >> >> -Dan >> >> >> >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >> > I share your concern. We could fix the concern if we created the >> > transformed pom on disk so that things like GPG signatures were generated >> > correctly, but AIUI the issue there was that the pom could not be put in >> > target as that would break relative paths. >> > >> > I suspect this is also related to the issue of dependency reduced poms >> for >> > shade... or any feature where the pom to be used downstream in the >> reactor >> > needs to differ from the pom on disk. >> > >> > For me, having been burned by not building the effective pom from a clean >> > checkout I actually favour the use of the release plugin, typically for >> CD >> > I just have the next development version the same as the current and if >> you >> > tune your preparationGoals then you can just have one compile test >> cycle... >> > >> > But the fight of that blog is a bit like the idiotic quest people have to >> > run the tests once only with code coverage as part of the single test >> > execution... until you have been burned by the code coverage affecting >> > effective bytecode and preventing the synchronization bug from being >> caught >> > by your tests (plus other test invalidating behaviours I have seen) you >> > will run around trying to get rid of the second test execution... >> > >> > Those who do not understand why we do things will be condemned to repeat >> > our mistakes that made us do things that way. >> > >> > Having said that, it is a good pressure to have people pushing the "why >> do >> > we need to do it this way" envelope... perhaps it is time that we need to >> > ensure that the release plugin has a page outlining our rational for the >> > current default behaviour, common ways to tweak it and stressing that we >> > have provided a framework for releasing and others are welcome to reuse >> the >> > framework in their own release plugins >> > >> > On 16 April 2016 at 06:01, Dan Tran wrote: >> > >> > > Hi, >> > > >> > > Anyone practicing CD according to this blog? >> > > https://axelfontaine.com/blog/dead-burried.html >> > > >> > > I can build locally, but have a huge concern on the pom deployed at >> maven >> > > repo since it does NOT have the exact version >> > > >> > > If you do, please share your experience. Any hick up when you introduce >> > > this new practice? >> > > >> > > For our case, we have about 200 modules project and about 100 dev + qa >> > > >> > > Thanks >> > > >> > > -Dan >> > > >> > >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
