在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):akhikhl/multiproject-git-gradle开源软件地址(OpenSource Url):https://github.com/akhikhl/multiproject-git-gradle开源编程语言(OpenSource Language):Groovy 100.0%开源软件介绍(OpenSource Introduction):#multiproject-git-gradle ##Overview This is gradle script for multiple git-repository setup, configuration and build. It supports automated cloning/pulling git-repositories (from any repositories, supported by JGit) and typical gradle tasks ("build", "clean", etc) that can be run against some or all repositories. Repositories can be supplied with inter-repository dependencies, so that particular order of assembly/testing/etc is guaranteed. Many thanks to the creators of gradle-git plugin ( https://github.com/ajoberstar/gradle-git ) for their excellent work, which is used by multiproject-git-gradle. Content of this document
##Required files To start using multiproject-git-gradle, you need two files: "build.gradle" - taken from this repository, this is gradle script. "config.gradle" - you write it yourself, according to your needs. You can use "config.gradle" from this repository as an example/starting-point for editing. See more information on this in chapter Configuration. ##Command line syntax Like with any other gradle script: gradle [some task names specified here] See Supported Tasks for more information on concrete tasks and their semantics. It is possible to start gradle without task: gradle then the default task buildApps is executed. ##Supported tasks ###build task build task allows to build multiple gradle projects (from different git-repositories) in an automated way. It does the following: Iterates all projects described in configuration, performs the following for each project:
Note that "build" task does not depend on "update" task, but all "build" steps are performed strictly after corresponding "update" steps. That means: a) if you routinely run "gradle build", it will not pull the changes from git-sources, but only compile things for you. Only if some projects are missing, they will be cloned from git-sources. b) if you run "gradle update build", it is guaranteed, that every project is first updated (cloned or pulled from repository) and only then built. ###buildApps task buildApps is an optional task, allowing to build "apps" sub-projects of multiple gradle projects (from different git-repositories) in an automated way. It does the following: First it builds all projects, as described in build task. Then it iterates all projects described in configuration, performs the following for each project:
###buildExamples task buildExamples is an optional task, allowing to build "examples" sub-projects of multiple gradle projects (from different git-repositories) in an automated way. It does the following: First it builds all projects, as described in build task. Then it iterates all projects described in configuration, performs the following for each project:
###clean task clean task allows to clean multiple projects (from different git-repositories) in an automated way. ###gitBranchList task TODO: document this task! ###gitStatus task TODO: document this task! ###update task update task allows to clone/pull multiple projects (not necessarily gradle-projects) from git-sources in an automated way. It does the following: Iterates all projects described in configuration, checks each project, whether it exists, then:
###uploadArchives task TODO: document this task! release taskThis task performs full release process on multiple git projects. See more information at Automated Release Feature (ARF). ##Configuration "build.gradle" (of multiproject-git-gradle) reads "config.gradle" file in order to "understand" project structure. "config.gradle" is being interpreted by gradle, therefore it should comply to gradle syntax. Absolutely minimal version of "config.gradle" (which is useless, but "well-formed" in a sence of multiproject-git-gradle) looks like this: multiproject {
} ###Specifying projects The simplest usable configuration looks like this: multiproject {
project name: 'ProjectA'
project name: 'ProjectB'
} where ProjectA and ProjectB must designate existing subfolders of the current folder. Effect: when you run "gradle build", multiproject-git-gradle will consequently build each project specified in multiproject configuration. ###Configuring inter-project dependencies You can specify inter-project dependencies the following way: multiproject {
project name: 'ProjectA'
project name: 'ProjectB', dependsOn: 'ProjectA'
project name: 'ProjectC', dependsOn: 'ProjectA'
project name: 'ProjectD', dependsOn: [ 'ProjectB', 'ProjectC' ]
} Rules:
###Configuring git-repositories There are two ways to specify git-repositories: via gitBase property and via gitSource property. ####Configuring gitBase property gitBase specifies "base" URL, from where the project(s) come. It supports all protocols supported by JGit library (for example, "http", "https", "git", "ssh"). gitBase can be specified "globally", for project group or for individual projects: multiproject {
gitBase = 'https://github.com/someUser'
project name: 'ProjectA'
git gitBase: 'https://github.com/anotherUser', {
project name: 'ProjectB'
project name: 'ProjectC'
}
project name: 'ProjectD', gitBase: 'https://github.com/thirdUser'
} Rules:
In the concrete example (above) "ProjectA" will be cloned/pulled from "https://github.com/someUser/ProjectA.git", "ProjectB" will be cloned/pulled from "https://github.com/anotherUser/ProjectB.git", "ProjectC" will be cloned/pulled from "https://github.com/anotherUser/ProjectC.git" and "ProjectD" will be cloned/pulled from "https://github.com/thirdUser/ProjectD.git". ####Configuring gitSource property gitSource property represents complete URI to git-repository and is not combined with anything. It supports all protocols supported by JGit library (for example, "http", "https", "git", "ssh"). multiproject {
gitBase = 'https://github.com/someUser'
project name: 'ProjectA'
project name: "ProjectB", gitSource: "https://anotherdomain.com/someDifferentProjectName.git"
} Rules:
In the concrete example (above) "ProjectA" will be cloned/pulled from "https://github.com/someUser/ProjectA.git", "ProjectB" will be cloned/pulled from "https://anotherdomain.com/someDifferentProjectName.git". ####Configuring gitNameSeparator and gitNameSuffix By default, if a project does not have gitSource property, it's effective git repository URI is calculated by formula: URI = gitBase + "/" + name + ".git" You can fine-tune this formula by specifying gitNameSeparator and gitNameSuffix: either globally, per-group or per-project: multiproject {
gitBase = 'https://github.com/someUser'
project name: 'ProjectA'
git gitBase: 'git@someGitoliteRepository', gitNameSeparator: ':', gitNameSuffix: '', {
project name: 'ProjectB'
project name: 'ProjectC'
}
} In the concrete example (above) "ProjectA" will be cloned/pulled from "https://github.com/someUser/ProjectA.git", "ProjectB" will be cloned/pulled from "git@someGitoliteRepository:ProjectB", "ProjectC" will be cloned/pulled from "git@someGitoliteRepository:ProjectC". ###Configuring build property By default, multiproject-git-gradle builds all projects specified in multiproject configuration. You can fine-tune what and how is built by using "build" property: multiproject {
project name: 'ProjectA'
project name: 'ProjectB', build: false
project name: 'ProjectC', build: 'subFolder'
} Rules:
In the concrete example (above) "ProjectA" will be built in "ProjectA" subfolder, "ProjectB" will not be built, "ProjectC" will be built in "ProjectC/subFolder" subfolder. ###Configuring apps property If you specify "apps" property for a given project, multiproject-git-gradle defines additional task "buildApps", which can be called on command line as "gradle buildApps". multiproject {
project name: 'ProjectA', apps: true
project name: 'ProjectB', apps: "applications"
} Rules:
###Configuring examples property If you specify "examples" property for a given project, multiproject-git-gradle defines additional task "buildExamples", which can be called on command line as "gradle buildExamples". multiproject {
project name: 'ProjectA', examples: true
project name: 'ProjectB', examples: "samples"
} Rules:
Configuring skipTests propertyBoolean property skipTests allows to enable and disable unit-tests on all projects or individual projects: multiproject {
skipTests = true
project name: 'ProjectA'
project name: 'ProjectB', skipTests: false
} By default skipTests is globally set to false, i.e. unit-tests are enabled. Automated Release FeatureSince version 1.0.12 multiproject-git-gradle implements Automated Release Feature (AFR), which allows to release the software from multiple git repositories. AFR is implemented as part of multiproject-git-gradle and accessible as a single task: "release". As with other tasks of multiproject-git-gradle, the file "config.gradle" defines upstream git repositories and inter-repository dependencies. ARF Requirements
How to start using ARF
ARF side effects
ARF release versionsARF uses the following algorithm for defining release version: It takes "version" property from the given project and matches it against regex: /(\d+)([^\d]*$)/ if project version matches this pattern, the release version is calculated as: m.replaceAll(m[0][1]) where m is an object of class java.util.regex.Matcher (the result of regex match). Example: if original version is "1.0-SNAPSHOT", the calculated release version will be "1.0". ARF new versionsARF uses the following algorithm for defining new version: It takes "version" property from the given project and matches it against regex: /(\d+)([^\d]*$)/ if project version matches this pattern, the new version is calculated as: m.replaceAll("${ (m[0][1] as int) + 1 }${ m[0][2] }") } where m is an object of class java.util.regex.Matcher (the result of regex match). Example: if original version is "1.0-SNAPSHOT", the calculated new version will be "1.1-SNAPSHOT". DSL for custom version incrementsYou can define your own rules for release version and new version with the help of multiproject-git-gradle DSL: multiproject {
git baseDir: 'upstream_repos', {
project name: 'project1'
project name: 'project3'
project name: 'project2', dependsOn: [ 'project1', 'project3' ], {
releaseVersion(/(\d+)([^\d]*$)/, { m -> m.replaceAll("${ m[0][1] }-RELEASE") })
newVersion(/(\d+)([^\d]*$)/, { m -> m.replaceAll("${ m[0][1] }-UNSTABLE") })
}
}
} in this example we define that project2 gets release versions that look like "X.Y-RELEASE" and new versions that look like "X.Y-UNSTABLE". releaseVersion and newVersion elements are actually functions, accepting two arguments: first one is regex, second one is closure. Closure is only invoked when the given regex is successfully matched against "version" property of "gradle.properties" file. Closure receives an object of class java.util.regex.Matcher (the result of regex match) as a parameter. Closure must return a string (or an object meaningfully convertible to string) containing version. It is possible to specify "global" releaseVersion and newVersion elements: multiproject {
releaseVersion(/(\d+)([^\d]*$)/, { m -> m.replaceAll("${ m[0][1] }-release") })
newVersion(/(\d+)([^\d]*$)/, { m -> m.replaceAll("${ m[0][1] }-unstable") })
git baseDir: 'upstream_repos', {
project name: 'project1'
project name: 'project3'
project name: 'project2', dependsOn: [ 'project1', 'project3' ], {
releaseVersion(/(\d+)([^\d]*$)/, { m -> m.replaceAll("${ m[0][1] }-RELEASE") })
newVersion(/(\d+)([^\d]*$)/, { m -> m.replaceAll("${ m[0][1] }-UNSTABLE") })
}
}
} in this example we define that project1 and project3 get gets release versions that look like "X.Y-release" and new versions that look like "X.Y-unstable", while project2 gets release versions that look like "X.Y-RELEASE" and new versions that look like "X.Y-UNSTABLE". It is possible to specify multiple releaseVersion and newVersion elements in the same scope, each one with it's own regex and closure. If there are multiple releaseVersion elements with the same regex in the same scope, only the last one is used, the previous ones are ignored. If there are multiple newVersion elements with the same regex in the same scope, only the last one is used, the previous ones are ignored. releaseNoPush propertyreleaseNoPush boolean property could be defined either in context of multiproject element or in context of project element: multiproject {
releaseNoPush = true
git baseDir: 'upstream_repos', {
project name: 'project1', releaseNoPush: true
project name: 'project3'
project name: 'project2', dependsOn: [ 'project1', 'project3' ]
}
} when releaseNoPush=true, ARF commits release and new versions, but does not push anything upstream. releaseNoCommit propertyreleaseNoCommit boolean property could be defined either in context of multiproject element or in context of project element: multiproject {
releaseNoCommit = true
git baseDir: 'upstream_repos', {
project name: 'project1', releaseNoCommit: true
project name: 'project3'
project name: 'project2', dependsOn: [ 'project1', 'project3' ]
}
} when releaseNoCommit=true, ARF does not commit nor push release and new versions. Publishing to maven repositoriesSince version 1.0.25 multiproject-git-gradle supports publishing both to local maven repo and any remote maven repo (like artifactory). Below are the detailed instructions. Prerequisites
Publishing to local maven repo
multiproject {
releaseDeployTasks = ['install']
git baseDir: 'upstream_repos', {
project name: 'project1'
project name: 'project3'
project name: 'project2', dependsOn: [ 'project1', 'project3' ]
}
}
Effect: the release versions and new versions will be installed to local maven repo (~/.m2) after the commit to git. The exact sequence is:
Publishing to remote maven repo (artifactory)
multiproject {
releaseDeployTasks = ['uploadArchives']
git baseDir: 'upstream_repos', {
project name: 'project1'
project name: 'project3'
project name: 'project2', dependsOn: [ 'project1', 'project3' ]
}
}
rootProject {
ext {
artifactoryReleases = [ url: 'protocol-host-and-port/artifactory/libs-release-local', user: 'UploadUser', password : 'UploadPassword' ]
artifactorySnapshots = [ url: 'protocol-host-and-port/artifactory/libs-snapshot-local', user: 'UploadUser', password : 'UploadPassword' ]
}
}
afterProject { proj ->
if(proj.plugins.findPlugin('maven') && proj.uploadArchives instanceof org.gradle.api.tasks.Upload) {
proj.configurations {
deployerJars
}
proj.dependencies {
deployerJars 'org.apache.maven.wagon:wagon-http:2.4'
}
proj.uploadArchives {
repositories.mavenDeployer {
configuration = proj.configurations.deployerJars
if(proj.version.contains('-SNAPSHOT'))
repository(url: rootProject.ext.artifactorySnapshots.url) {
authentication(userName: rootProject.ext.artifactorySnapshots.user, password: rootProject.ext.artifactorySnapshots.password)
}
else
repository(url: rootProject.ext.artifactoryReleases.url) {
authentication(userName: rootProject.ext.artifactoryReleases.user, password: rootProject.ext.artifactoryReleases.password)
}
}
}
}
} where "protocol-host-and-port" should be replaced with concrete protocol, host and port of target maven repository, "UploadUser" should be replaced with an existing user and "UploadPassword" should be replaced with a valid password.
Effect: the release versions and new versions will be deployed to remote maven repo after the commit to git. The exact sequence is:
##Copyright and License Copyright 2013 (c) Andrey Hihlovskiy All versions, present and past, of "multiproject-git-gradle" script are licensed under MIT license: You are encouraged to use it to whatever purpose and whichever way, all for free, provided that you retain copyright notice at the beginning of the script. |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论