How to configure gradle for multi project builds and publishing?

Dear all,

I am quite new to gradle and even after reading a lot in this forum, I am a little bit confused with multi project configurations and multi project publishing.

What I learned so far:

  1. In a repository with multi project builds, there is only one settings.gradle on the repo level while the build.gradle is only defined on the (sub-) project level. Hence, there is no build.gradle on the repo level: Structuring and Building a Software Component with Gradle
  2. As of gradle 7, there is a new central declaration of repositories in the settings.gradle: Gradle | What's new in Gradle 7.0

However, I have the following questions:

  1. Can I define variables for the repositories, such that I can reuse the repository (name, url, credentials) in all my (sub-) projects for the publishing task. Ideally, this could be something like this in each sub project
publishing {
    publications {
        myLibrary(MavenPublication) {

    repositories {
        maven **myRepoVarDefinedInTheGradleSettings**
  1. What are the things that I really need to specify in the publication section? What about groupId, artifactId, version and (JDK) versionMapping?

  2. Is there a central place, where I can define general plugins and settings like the following idea plugin? I tried to create a build.gradle on the repo level once, but it did not seem to be considered…

apply plugin: 'idea'
idea {
    module {
        downloadJavadoc = true
        downloadSources = true
  1. Are there any pros and cons of using a buildSrc folder? I somehow got the impression that this is an old way of structuring builds but never understood when/how/why to use buildSrc

Sorry for these stupid questions. Any help is much appreciated, thanks!

1 Multi project builds. I see in majority of cases that even the root of the project contains build.gradle file as well. Just look at It contains build.gradle script in the root project that applies plugins, adds repositories and does some additional configuration.

4 About why to use buildSrc you can check this StackOverflow page. I used it in the past to do exactly what is described in the answer. Te develop a plugin inside buildSrc that can be structured into multiple separate classes which are compiled before the build.script in root subprojects are executed. It doesn’t need to be plugin. You can also implement different tasks in separate class files that are then reused in subprojects.

Con: logic in buildSrc can’t be shared between other stand alone projects.