RE: AW: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Robert Patrick
SNAPSHOTs work fine within a project, having SNAPSHOT dependencies across projects is tricky and probably best avoided. If the two projects are truly worthy of their own independent project, then the cross-project dependencies should probably not be using SNAPSHOT dependencies. If you follow

AW: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Hohl, Gerrit
Hello, thanks Robert, thanks Stephen and thanks Irfan for your replies. Somehow it seems no easy to handle this. And it also seems to break the principals of that book in one point or another (strict dependencies, not checking in into the SCM during the process, etc.). That makes me wondering

Re: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Robert Patrick
While having the developers update the POM may sound ok, it turns out to be problematic in practice when there are more than a handful of developers. In a previously life, we had an elaborate scheme where we had scripts that the developer had to run to update the POM and dependency version

Re: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Stephen Connolly
Well if you have a true CD deployment and keep strictly to not breaking backwards compatibility then you can use version ranges for upstream dependencies... if that is setting alarm bells off then developers will need to either have Jenkins update their poms for them or will have to view updating

Re: AW: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Robert Patrick
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

Re: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Irfan Sayed
here is what needs to be done: - while building the packages, use the mvn option -DnewVersion and replace the new version in POM.xml. this will happen through Jenkins server (for example CI server ) . for this, you need to make all POMs writable. - once the packages are built with new

AW: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Hohl, Gerrit
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

AW: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Hohl, Gerrit
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): com.company project-a

Re: Maven and Continous Integration / Continous Delivery

2016-04-20 Thread Stephen Connolly
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}"

Maven and Continous Integration / Continous Delivery

2016-04-20 Thread 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

Re: Hickup in multi thread build

2016-04-20 Thread Dan Tran
Hi Fabian I will give your extension a try Thanks -Dan On Wed, Apr 20, 2016 at 12:26 AM, Fabian van der Veen < f.van.der.v...@topdesk.com> wrote: > Hey, > > The way you describe it; this sounds like a problem I also encountered in > our (similar sized) project here. > I reported this here:

Re: Hickup in multi thread build

2016-04-20 Thread Fabian van der Veen
Hey, The way you describe it; this sounds like a problem I also encountered in our (similar sized) project here. I reported this here: https://issues.apache.org/jira/browse/MNG-5960, which has been linked as related to https://issues.apache.org/jira/browse/MNG-5750. Troubleshooting boiled down