'Parent' build.gradle file

I originally posted this on stackoverflow but didn’t really get a response, so I figured I’d try it here. I’ve narrowed it down somewhat.

My organization uses the same Gradle plugins and dependencies for a lot of our projects. My custom plugin knowledge is pretty weak, but what I’d like to do is wrap these plugins and dependencies into a single, reusable source file that ‘expands’ in the new project. Here’s a proof of concept:

// build.gradle from 'parent' build.gradle
plugins {
  id 'war'
  id 'org.springframework.boot' version '2.2.4.RELEASE'
  id 'io.spring.dependency-management' version '1.0.9.RELEASE'
  id 'org.asciidoctor.convert' version '1.5.8'
}
	
dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-web'
  testImplementation 'org.springframework.boot:spring-boot-starter-test' {
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
  }
  testImplementation 'org.junit.jupiter:junit-jupiter-engine'
}
	
test {
 useJUnitPlatform()
}
	

and attempting to reference from another project, it’s the only line in the file:

	
apply from: '<path-to-above>/build.gradle'
	

This error I get is the following:

  script '<path-to-above>/build.gradle': 15: Only Project build scripts can contain plugins {} blocks

  See https://docs.gradle.org/5.5.1/userguide/plugins.html#sec:plugins_block for information on the plugins {} block
   @ line 15, column 1.
     plugins {
     ^
  1 error

Am I on the right track?

Thanks

You are not able to use the plugins { } block anywhere except the build.gradle file for a project. You would need to fall back to buildscript { } instead if you use script plugins.

However, script plugins are designed for organizing logic in a project, not for sharing build logic between independent projects. For the case that you describe, a standalone, binary plugin is the preferred approach to share logic between independent projects. Ideally you write tests to verify this logic as well.

Your original post on SO before the edit was much closer to what you should have for the case described, but with a few implementation issues. I’ve provided a more detailed response there on those particular items.

For a plugin to apply other plugins, you may find this approach useful