[Thanks to Jason Porter for pointing me here from the user group]
Hello all,
We use continuous deployment at my company in its truest form: everyone is always committing and deploying, all the time. We have a bunch (200+) of java projects, many linked in some way as a dependency. E.G. We have may project A, which depends on B and C. C may also depend on D, while B depends on E. All of these may have external dependencies too.
We have been using a custom built deploy script, mixed with Maven for this dependency management. For normal external dependencies it checks the maven2 central repositories. For internal dependencies, our deploy script parses the pom.xml (and pom.xml of all dependencies recursively) and checks out the source for each from SVN. It then does maven install/build on each of those, until we can finally build end result, project A. When we deploy, we always check out the latest version of each of our internal dependencies.
In practice this isn’t as horrible as it may sound, but I’d like to make it better. Gradle looks really interesting, but I’m not sure it supports our needs:
Basically we need to be able to specify dependencies that are external (maven2 repo), but also be able to specify internal ones by pointing to a particular project name or source control repo. Ideally it would work on both svn and git. Example (not in proper gradle syntax, since I haven’t yet fully learned it):
project A {
dependency ‘b’ ‘https://mysvnrepo.com/svn/someProjectB’
dependency ‘c’ https://myGITrepo.com/git/someProjectC’
dependency ‘d’ mavenRepository() }
Each of those dependencies B and C could have further dependencies, and each would have a build.gradle/settings.gradle so that we could check out recursively. It is important that the build does not specify a specific version, and always pulls HEAD from the repo and builds that. We have no notion of version numbers, like I said.
Is this something gradle can support (now or in the future), or do you know of something that can?
I noticed the multi-project mode of gradle, but I’m not sure it supports this either. While we are virtually set up like your example, with a base folder and a bunch of sub projects, we never ever are deploying all of them at once. It seems like the current multi-project mode would require you to check out the entire repository (all 200+ “subprojects”), under a base project to do the deploy. We may only actually need like 3-10 of those, and checking them all out is time consuming.
Thoughts?
Thanks,
Bryan