Inheriting from a parent not in the same project

Is there a similar concept to a Maven non-local parent project in Gradle? My dev team has several independent and unrelated projects in flight. In Maven, I can (and did) write a parent pom that’s inherited by all of the projects to set up common things like repository locations and some basic dependency management to keep things like junit and logging relatively consistent across all the projects. That pom has packaging=pom and is itself the only “artifact” of that build. Having all our projects inherit from this common parent prevents a lot of copy/paste coding in the project poms, which otherwise would have to redefine all of that stuff themselves, and then have to be kept in sync any time something changed. I can’t seem to find any similar feature in Gradle, and I’ve already got a sense of dread at all the copy/pasting that’s going into my second gradle project. Can someone show me the error of my ways? I just can’t imagine there’s not a way to solve this with gradle. Actually, an ideal solution would let my gradle builds inherit from the same Maven parent pom that my Maven projects already do.

You have several options to define this kind of company/department standards across multiple ‘unrelated’ projects. Here are some of them:

  • You can define a gradle script that contains the shared setup. Then you can host this script at your repository manager and let all your projects apply this script like this:
apply from:'http://mycompany/repository/dep1/build/dep1.gradle'
  • You write a custom plugin (E.G MyDevTeamPlugin), that defines and introduce these kind of common informations to all of your builds. Have a look at the according section in the gradle userguide for detailed information (http://gradle.org/docs/current/userguide/userguide_single.html#custom_plugins)

  • You ship your own department specific gradle distro and put your department logic into GRADLE_HOME/init.d/. This approach works also great if you use the gradle wrapper and share your distro via your repository manager. This way you can easily manager your gradle versions and avoid problems on distributing them.

  • You can combine 2 + 3

does that help you? regards, Rene

Yes, that’s exactly what I was looking for. Thanks!

I’ve been thinking about it a little, and it seems that option 1 would be the simplest, except that–barring manually uploading the script to the maven repo–I think you’d need two gradle scripts or a script and a pom to do it properly. If you put the necessary elements in the script to upload it to the repo, then that would pollute anything that “inherited” from that script, right?

Is there any corollary in gradle to maven’s “packaging=pom” that declares "this build script is the artifact that should be uploaded, which wouldn’t be “inherited”? If you have to manually set it up in the script, then I think you’re always stuck.

As I think about it more, I’m thinking the plugin approach might be the more desirable alternative.

the dept.gradle: --------------------------------------------------------------------

buildscript {
 repositories {
  maven {
   credentials {
    username = nexusUsername
    password = nexusPassword
   }
   url repositoriesUrl
  }
 }
    dependencies {
  classpath group: 'groupx', name: 'xx-gradle-plugin', version: '1.0-SNAPSHOT'
 }
}

the build.gradle


apply from:'http://mycompany/repository/dep1/build/dept.gradle'
apply plugin: 'xx'

then ------------------------------------------------------------

* What went wrong:
A problem occurred evaluating root project 'spring-yy'.
> Plugin with id 'xx' not found.
  * Try:
Run with --info or --debug option to get more log output.

Is ‘xx’ the correct plugin ID? Also, bringing in a ‘buildscript’ section with a script plugin isn’t officially supported. You might have to inline the ‘buildscript’ section (only in the root project).

xx is the correct plugin ID. Could gradle support it in the future? Or I can do it myself?

It’s more likely that we will provide other ways to bring in third-party plugins with even less code. Today there is no way around having one ‘buildscript’ section per build.

@Rene Groeschke is there a way to override some property from the “parent gradle script”?

I’m trying to setup a gradle script that will upload artifact to a maven repository. And I would like to have a property for the artifactId and be able to override it.

I too wanted this type of feature, I have created a plugin to provide this type of feature, here: https://github.com/boxheed/gradle-pater-build-plugin