CODEWITHSUNDEEP
mavenmaven-3gradle
Matt
Matt

Reputation: 8476

How to share a common build.gradle via a repository?

I'm looking at porting a maven build to gradle. One feature of maven is pom inheritance whereby I can declare a variety of common behaviour in a pom, publish that to a repository and then use that via the <parent> element in a concrete project.

My Q is simply whether there is an equivalent behaviour in gradle?

I've previously done this in ant+ivy by importing a common build.xml which relied on either having already checked out the location of the common build.xml from source control or using something like svn:externals. I can repeat this approach without any real difficulty but this seems to be one thing maven does quite nicely so it would be nice to see something similar in gradle.

Upvotes: 30

Views: 19832

Answers (9)

Tomas Bjerre
Tomas Bjerre

Reputation: 3500

I see 2 main problems with sharing build script:

  • How to distribute the shared script.
  • How to make it configurable and re-usable for all your needs.

I am distributing it in a jar. I release that jar to Maven Central.

I make it re-usable by creating a defaultCOnfig in the script. And a buildConfig in projects using it. Those are merged, in the script to create an effective config.

My projects may have build.gradle looking something like this:

apply plugin: 'java'

buildscript {
 repositories { mavenCentral() mavenLocal() }
 dependencies { classpath 'se.bjurr.gradle:gradle-scripts:2.+' }
}
project.ext.buildConfig = [
  publishing: [
    relocate: [
      "org:org",
      "com:com"
    ]
  ],
  manifest: [
    mainClass: 'se.bjurr.gitchangelog.main.Main'
  ]
]
apply from: project.buildscript.classLoader.getResource('main.gradle').toURI()


dependencies {
 ...
}

I have my code here: https://github.com/tomasbjerre/gradle-scripts

I also blogged about it here: https://tomas-bjerre85.medium.com/a-sustainable-pattern-with-gradle-e8bf6eb746ff

Upvotes: 0

Yonghua Li
Yonghua Li

Reputation: 31

Directly reading the common script in a jar like the following way. Unpackaging the jar is not needed.

apply from: this.getClass().getClassLoader().getResource("path to dependency.gradle")

Upvotes: 3

Rares Oltean
Rares Oltean

Reputation: 666

Here's an improvement to the accepted solution, for when you have more than one dependency in your buildscript:

buildscript {
    repositories {
        // Repositories
    }
    dependencies { 
        classpath 'com.foo.bar:project-extension:1.0.0'
        classpath 'com.foo.bar:some-dependency-1:2.0.0'
        classpath 'com.foo.bar:other-dependency-1:3.0.0'
    }
    dependencies {
        delete "gradle/ext"
        def jars = configurations.classpath.files as List<File>
        ant.unjar src: jars.find { it.name.matches '.*project-extension.*' }, dest: 'gradle/ext'
    }
}

apply from: 'gradle/ext/common.gradle'

Worked like a charm for me.

Upvotes: 3

Hao
Hao

Reputation: 131

I like your approach @user3394219

I wrote a small plugin doing the similar thing:

plugins {
    id "com.orctom.applyscript" version "1.1"
}
applyscript '{{groupA}}:{{nameA}}:{{versionA}}/{{path-of-fileA.gradle}}'
applyscript '{{groupA}}:{{nameA}}:{{versionA}}/{{path-of-fileB.gradle}}'
applyscript '{{groupA}}:{{nameA}}:{{versionB}}/{{path-of-fileC.gradle}}'
applyscript '{{groupC}}:{{nameD}}:{{versionE}}/{{path-of-fileX.gradle}}'

or

plugins {
    id "com.orctom.applyscript" version "1.1"
}
dependencies {
    scripts '{{groupA}}:{{nameA}}:{{versionA}}'
    scripts '{{groupA}}:{{nameA}}:{{versionB}}'
    scripts '{{groupC}}:{{nameD}}:{{versionE}}'
}

applyscript '{{nameA}}-{{versionA}}/{{path-of-fileA.gradle}}'
applyscript '{{nameA}}-{{versionA}}/{{path-of-fileB.gradle}}'
applyscript '{{nameA}}-{{versionB}}/{{path-of-fileC.gradle}}'
applyscript '{{nameD}}-{{versionE}}/{{path-of-fileX.gradle}}'

https://plugins.gradle.org/plugin/com.orctom.applyscript

Upvotes: 2

user3394219
user3394219

Reputation: 71

My version:

repositories {  
    <your repos>
}  
configurations {   
    scripts   
}  
dependencies {  
    scripts group: 'org.foo', name: 'build', version: '1.0.0', ext: 'gradle' 
    // add more scrips if needed 
}  
configurations.scripts.resolve().each { apply from: it }

Upvotes: 7

user1644873
user1644873

Reputation: 1231

I have an answer and another question:

First, to access a shared file from a repository (i.e. Nexus) you can build a URL that includes a query:

apply from: 'http://server-url/nexus/service/local/artifact/maven/redirect?r=repository-name&g=group-name&a=build-common&e=gradle&v=LATEST'

I did this for our project and it works great. I can manage the 'build-common.gradle' file in a separate SVN project and upload it to Nexus as a SNAPSHOT. The above URL (with appropriate values inserted for 'server-url', 'repository-name', and 'group-name') finds the latest SNAPSHOT of my .gradle script I uploaded. No need to package it in a jar.

Upvotes: 9

Patrick Bergner
Patrick Bergner

Reputation: 623

Buildings on Matt’s solution, I find the following to be a bit cleaner:

buildscript {
  repositories {
    <your repos>
  }
  dependencies {
    classpath '<your jar>'
  }
}

afterEvaluate { project -> // afterEvaluate for resolving the build script dependency
  apply from: project.buildscript.classLoader.getResource('path/to/your/resource/in/the/jar').toURI()
}

Just my two cents. :-)

Upvotes: 15

Matt
Matt

Reputation: 8476

My current solution is option 3; package the common scripts into a jar as resources and then unjar during the buildscript section like so

buildscript {
    repositories {
        // enterprise repo here
    }
    dependencies { 
        classpath 'com.foo.bar:common-build:0.1.0-SNAPSHOT'
    }
    dependencies {
        ant.unjar src: configurations.classpath.singleFile, dest: 'build/gradle'
    }
}

apply from: 'build/gradle/common.gradle'

This seems to do what I want.

Upvotes: 16

Peter Niederwieser
Peter Niederwieser

Reputation: 123910

There are two possibilities:

  1. Publish a build script to a web server, and include it with apply from: "http://path/to/script.gradle"

  2. Write a Gradle plugin, publish it as a Jar to a Maven or Ivy repository, and include it with:

    buildscript {
    repositories { .. }
    dependencies "mygroup:myplugin:1.0"
}

apply plugin: "myplugin"

The second option is more complicated, but also somewhat more powerful. For example, plugin Jars will be cached, whereas remote build scripts currently won't. In general, I recommend to start with 1., and move to 2. if and once it becomes necessary. In the future, Gradle will likely offer a mechanism which combines the ease of use of 1. with the advantages of 2.

Upvotes: 24

Related Questions