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
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
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
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
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
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
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
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
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}"
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
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:
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
12 matches
Mail list logo
