Multiproject vs Composite. What to choose?


(Josh) #1

Hi all,

I’m switching from ivy/ant to gradle and I’m wondering how to archive the following.

Situation:

  1. I have 2 svn repositories with in total 100 java projects. The projects depend on each other directly or through transitive dependencies (so quite normal I guess). Currently the build.gradle files are single builds with external dependencies (resolved through an artifactory instance).

  2. I have a Jenkins instance which I need to use for doing continous build (later continious delivery). Each jenkins job currently produces a jar or war file to an artifactory instance. A project build should trigger an upstream build but that’s not working as they’re all “individual projects” from the gradle perspective.

  3. Developers must be able to check out and work with a single project (not sure if thats possible when I would use a multi project structure)

  4. There are common configuration things which I want to share across projects (like versions, server urls,…)

My problems are:

  1. A multiproject build wouldn’t give me the possibility to work on individual projects (or does it? If yes how?)

  2. A composite build won’t give me the Jenkins functionality to trigger upstream builds and I’m not sure if transitive dependencies of projects are handled correctly.

How would you guys start to archive the goals?


(Stefan Oehme) #2

If two things have the same version and release cycle, then they should be in a multi-project build. If they are independent of each other, they should be in independent builds.

Jenkins can be configured to kick off downstream builds. You could automate the creation of your Jenkins jobs with the gradle-jenkins-plugin. That way you could basically iterate through all your projects, analyse their dependencies and set up Jenkins job dependencies based on that.

Common configuration can be shared through either a plugin that everyone applies or even more conveniently through a custom Gradle distribution that everyone uses.


(Josh) #3

Thank you for the quick answer! I wasn’t aware of the gradle-jenkins-plugin. Looks promising :). I think I’ll go for a multi project build. It’s always the same version number. Guess it makes more sense to digg in this direction. Thank you!


(Stefan Oehme) #4

If it’s one big build then Jenkins config becomes trivial, as there will be no more downstream jobs, everything would be built in one go.