Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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.

like image 661
Matt Avatar asked Mar 02 '12 20:03

Matt


People also ask

How do I share my gradle project?

The most reliable way to share configuration between builds is to code it up as a plugin class (i.e. a class implementing the org. gradle. api. Plugin interface), publish it as a Jar to a Maven or Ivy repository, and pull it in to consuming builds using a buildscript block.

Does gradle have a repository?

Gradle can consume dependencies available in the local Maven repository. Declaring this repository is beneficial for teams that publish to the local Maven repository with one project and consume the artifacts by Gradle in another project. Gradle stores resolved dependencies in its own cache.


1 Answers

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.

like image 94
Peter Niederwieser Avatar answered Sep 25 '22 00:09

Peter Niederwieser