To share stuff within multiple projects of the same build, use allprojects { ... }
, subprojects { ... }
, etc. Also, extra properties (ext.foo = ...
) declared in a parent project are visible in subprojects. A common idiom is to have something like ext.libs = [junit: "junit:junit:4.11", spring: "org.springframework:spring-core:3.1.0.RELEASE", ...]
in the top-level build script. Subprojects can then selectively include dependencies by their short name. You should be able to find more information on this in the Gradle Forums.
To share logic across builds, you can either write a script plugin (foo.gradle
), put it up on a web server, and include it in builds with apply from: "http://..."
, or write a binary plugin (a class implementing org.gradle.api.Plugin
), publish it as a Jar to a repository, and include it in builds with apply plugin: ...
and a buildscript {}
section. For details, see the Gradle User Guide and the many samples in the full Gradle distribution.
A current limitation of script (but not binary) plugins is that they aren't cached. Therefore, a build will only succeed if it can connect to the web server that's serving the plugin.
As to your second question (which should have been a separate question), there are a couple of third-party release plugins available, for example https://github.com/townsfolk/gradle-release.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…