Is it possible/reasonable to setup a build system with sub projects that are on different source control repositories?

(Jason Zwolak) #1

Say I have a rich internet client project that has the sub projects: rest service, desktop client, and common. Where the rest service goes on the server and is accessed by the desktop client via the JAX-RS client api. The common project contains things like entity classes which are shared across the server and client.

This is in fact the project I have.

Is it recommended that all these sub projects and the parent project be at the same source control URI? Currently they are not and I’m integrating the build systems and wondering if I should move all the repositories into one (which would be a pain and probably lose some history).

If it’s reasonable and possible, I’d like to have the parent project checkout/update the the sub projects from their respective URIs. The work flow would look like this:

git clone parent_project  cd parent_project  gradle initialize_sub_projects  

The last step would check out the sub projects from their respective URIs. I actually have the beginnings of something like this working, but I’d like to get a second opinion… my initial problem is that the sub projects either have to know they are part of the parent (so that project/task paths have the right parent project) or their tasks cannot be run from the parent project with something like


Is this advisable? Or should I merge all the source control repositories to one?

(Jason Zwolak) #2

Based on my reading of the Gradle user’s guide, seems like I should keep the projects separate, publish to a local (or in house) repository, and declare the necessary dependencies between projects.

(Luke Daley) #3

It takes some work to pull this off. The guys from Prezi have released a tool for doing this with Gradle:

(Jason Zwolak) #4

This is precisely what I need!

I’d like to add this quote from the blog about what Pride does for the problem I’m facing:

What [ivy, maven, and gradle] don’t have an answer for is how to tie these components together in the local development environment. According to them, components are independent entities, and only the binary artifacts they build are connected via dependencies. As long as you are working with a single component at a time, this model works fine.