On 24 July 2015 at 12:18, Paul Benedict <pbened...@apache.org> wrote:
> It sounds like both your projects are snapshots. So when you build > B-SNAPSHOT you have no idea what's inside of A-SNAPSHOT. If this is > bothersome to you, you can think about releasing milestone versions of A so > that B-SNAPSHOT always has a known/reliable codebase to work with. Perhaps > you want weekly snapshots to be released, for example, but you definitely > want to lock down A's version for B. Alternatively you can have Jenkin's use a per-project ~/.m2/repository. Before each build we delete the per-project .m2/repo so that previous builds don't pollute it. This does mean that each build requires every released version to be seeded into your .m2/repo - but this is retrieved from a network local repository server, so its mostly fast enough. Now you can build your jenkins projects for A and B knowing that they have their own .m2/repo and will build everything from source control. However Paul's comment would be a better approach. You should also think closely about release lifecylces, as the way you have it setup now you will need to release project A and B at the same time, as child projects should be released together with the parent. I think the advise for git is to make the relationship 1 git repo : 1 release cycle. That is, dont put A and B in the same git repo if you indent to release A and B on different cycles.
