Hello all,
We use continuous integration 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
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Gradle-with-continuous-integration-tp4847625p4847625.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
