It sounds like this would be a good solutions for us, until we fully move towards the correct versioning, described by Paul B. and you in the other mail.
Thank You all! Mark. On 23 July 2015 at 21:44, Barrie Treloar <baerr...@gmail.com> wrote: > On 24 July 2015 at 13:33, V. Mark Lehky <mark.le...@gmail.com> wrote: > >> Our release process is definitely: everything gets released at the same >> time (with the same version number). >> >> How do you create per-project .m2 repo via Jenkins? >> Is it just a case of deleting the repo before each build, or are there >> actually separate copies of repos on disk? > > > I won't claim that doing this is "best practice". > > You can't just delete the repo before each build, your machine has multiple > build threads right? So that would cause things to break. > > There is an option in the jenkins config under Build > Use private Maven > repository > ---- > Help for feature: Use private Maven repository > > Normally, Jenkins uses the local Maven repository as determined by Maven — > the exact process seems to be undocumented, but it's ~/.m2/repository and > can be overridden by <localRepository> in ~/.m2/settings.xml (see the > reference for more details.) > > This normally means that all the jobs that are executed on the same node > shares a single Maven repository. The upside of this is that you can save > the disk space, but the downside of this is that sometimes those builds > could interfere with each other. For example, you might end up having > builds incorrectly succeed, just because your have all the dependencies in > your local repository, despite that fact that none of the repositories in > POM might have them. > > There are also some reported problems regarding having concurrent Maven > processes trying to use the same local repository. > > When this option is checked, Jenkins will tell Maven to use > $WORKSPACE/.repository as the local Maven repository. This means each job > will get its own isolated Maven repository just for itself. It fixes the > above problems, at the expense of additional disk space consumption. > > When using this option, consider setting up a Maven artifact manager so > that you don't have to hit remote Maven repositories too often. > > If you'd prefer to activate this mode in all the Maven jobs executed on > Jenkins, refer to the technique described here. > --- > > Note: we use the evil Maven build job. > Read > http://javaadventure.blogspot.com.au/2013/11/jenkins-maven-job-type-considered-evil.html > for more on this. > > We got everything working - and haven't spent much effort refactoring this > stuff to best practices. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
