First off, this makes for an excellent question to post to forums.gradle.org so we can more easily share information. I'll post there too once it's up.
I'm very confident gradle can support what you need, hopefully without much custom code. In fact the custom code that I think you would need is a resolver, possibly something else as well, but I'll let the experts flesh that out. This may also be doable with a plugin which uses jgit and svnkit. To retrieve the source and issue a Gradle build. Sounds like a very interesting problem though! Sent from my iPhone On Sep 27, 2011, at 19:57, bryanb <[email protected]> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
