a couple corrections: * for Jenkins freeslyle, one can create a job parameter similiar to this format revision=x.y.x-${BUILD_NUMBER} to override the default maven version
* for Jenkins Pipeline, the revision handling is part of projec's t Jenkinsfile The original blog is here http://blog.soebes.de/blog/ 2017/04/02/maven-pom-files-without-a-version-in-it/ -D On Wed, May 3, 2017 at 5:54 PM, Dan Tran <dant...@gmail.com> wrote: > I am able to bring it to production with very small project with few > modules. Where I hook up jenkins build number with the version > > <revision>1.0.0-${env.BUILD_NUMBER}</revision> See Karl's Blog > > At the same time, use buildnumber-m-p to deploy text file with SCM info, > and finally push to staging repo using Artifactory > > Once a build is promoted (GAed), I then remove the rest from staging, and > manually tag the build using the recorded SCM info > > My next task is a much bigger project with 300+ modules and lots of > dev/qa. So it is crucial i dont break their development environments > > Thanks > > -Dan > > > On Wed, May 3, 2017 at 5:34 PM, Eric B <ebenza...@gmail.com> wrote: > >> Hi Karl, >> >> Can you provide a little more information how you are doing this? Or do >> you >> have a blog about it somewhere? It's something I desperately need to >> insert >> into my build pipeline but haven't had the time to work on yet. So far, >> the best I've been able to think of is to use a parameter for a build >> number, have Jenkins assign a build number, pass it to maven, and have the >> version reflect the build number using the external parameter. But I >> really don't like that idea as the version is now dependent on a variable, >> which I find is contrary to the whole concept. >> >> The other option is to have Jenkins took the build number in the pom using >> the release plugin or the version plugin, commit the new pom, and then >> build from a newly checked out code. My issue there is that I'm having >> Jenkins do a lot of scm manipulations which are more subject to failing >> (ie: version updates, commit, tag, push, etc). >> >> Finally, I'm trying to think of a good way of rolling all this into Nexus >> staging repos and only promoting a build out of a staging repo once it >> passes the pre prod environment and is certified for prod. >> >> Any ideas, thoughts, feedback and/or tips would be greatly appreciated. >> >> Thanks, >> >> Eric >> >> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote: >> >> > Hi Dan, >> > >> > I'm trying to do something in this direction starting next week... >> > >> > Apart from that already tested it with Eclipse Neon without any >> > issue...(at the moment only test projects with 10-15 modules)... >> > >> > But it works at the moment.. >> > >> > In the meantime I have found one issue which is related to >> > maven-enforcer-plugin where I already opened an issue for it [1].. >> > >> > Kind regards >> > Karl Heinz >> > >> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268 >> > >> > On 03/05/17 20:39, Dan Tran wrote: >> > >> >> Hi >> >> >> >> I have been experimenting with suggestion from Karl [1] with small >> multi >> >> module maven project. >> >> >> >> >> >> Is there any one actually bring this to production for large scale >> project >> >> yet? Love to learn from your experience integration specially with >> >> Jenkins, >> >> IDE ( eclipse, intellij, Netbean) >> >> >> >> this allows us to stop using maven-release-plugin >> >> >> >> Thanks >> >> >> >> -Dan >> >> >> >> [1] >> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou >> >> t-a-version-in-it/ >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> > >