I'm in the process of creating a multi-subproject Java project. The subprojects are to each have their own separate git repositories and be included in the superproject using git submodules. Our preferred case would be that our continuous-integration tool (Jenkins) would independently build these subprojects into .jars without taking into account or otherwise knowing about the superproject.
This can be accomplished pretty easily just by ensuring that the subprojects each have a build.gradle which has all of the information necessary to build the .jar that results from the build. The only complication that results is when some subprojects depend on other subprojects.
Even this is pretty straightforward if you're willing to always have the subprojects pull their dependencies' .jars from a Maven or Ivy repo. However, when we build on our local boxes during the course of development, we want to be able to build and deploy the superproject's .war file to Tomcat and all of the .jars to somewhere on the classpath and ensure that all of the .jars were built from the copy of the code currently on our own box. (That is, we want it to act basically as if we used compile(project(":otherproject")) rather than compile("group:otherproject:1.0-SNAPSHOT") or some such.)
I'm fairly new to Gradle, and it's entirely possible I'm missing something pretty obvious, but I haven't yet found a nice way to handle this.
We could do something such that the set of dependences for building it by pulling .jars from our Maven repository is in one file and the set of dependencies for building it by using its sibling subprojects in another file, but that seems like a DRY violation. (In that case, we'd have two separate places to manage the list of dependencies.)
We could create the subprojects' build scripts to always pull from the Maven repository and have the superproject's build script include sections for each subproject which override the dependencies in the subprojects, but that's just as much a DRY violation as the previous option.
I thought maybe about having the superproject actually introspect and modify the dependencies lists on each of the subprojects as necessary (the code in the superproject should have access to all of the information necessary to transform a dependency on a Maven artifact into the corresponding dependency on a sibling subproject, I'd think), but after looking into it quite a bit, I'm not sure how one would go about doing so.
I'm hoping you folks can help. Thanks!
Dynamically switching between project and external dependencies isn't currently a first-class feature in Gradle. However, there is Prezi's Pride tool, and I strongly recommend to give it a spin.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With