Sharing build configuration in a multi-project build (with sparse checkout)

Old Forum
#1

I’m attempting to migrate an existing Maven/subversion project to Gradle/subversion. I’ve got multiple module directories in my project, each with it’s own pom.xml file which references a parent pom.xml for version number and dependencies.

root
+-- pom.xml
+-- api
     +-- pom.xml
+-- impl
     +-- pom.xml
+-- web
     +-- pom.xml
+-- ... others w/potentially very large data footprints ...

In Maven, I need only check out the ‘web’ module from subversion and performing a build will cause Maven to automatically download the parent pom.xml file and bring in the current build version and shared dependencies. Is there an equivalent in Gradle?

My plan was to make a single, top-level build.gradle file which would contain all the module-specific dependencies as well as shared tasks and dependencies (gradle.properties would contain the build version). Unfortunately, using subversion, I’d have to check out the entire directory tree from ‘root’ (which can be very large) in order to work with just the ‘web’ module. There are implications that affect using Hudson/Jenkins as well (I’ve got automated builds of each module that kick off on a subversion commit to make sure all the code compiles and JUnit tests pass). Any suggestions/guidance on how to structure this in Gradle? Should I drop back to a build.gradle file for each module?

#2

If the only thing you are missing for your sparse checkout approach is a way to share configuration, you can put that configuration into a binary or script plugin and apply it to every project. But typically you also need to dynamically adapt settings.gradle and project dependencies to make sparse checkouts work. Gradle doesn’t yet have direct support for this, but with some effort you can script it yourself (or write a plugin).

As long as you don’t mind the checkout itself, checking out everything and working only on a subset of projects works quite well with Gradle due to its incremental build feature. This has other benefits like having a consistent view of the whole source tree. Pulling some subprojects from an artifact repository and building others yourself can easily lead to version hell, especially on a CI server.