How to work with gradle wrapper, init script, multi project and best with idea

Question

to sum up the components and environment:

• multi-project, typically each gradle project is soley in a seperate git
  • you don't want to use submodules
• gradle init scripts in a seperate config / super repository
• using gradle wrapper
• for the GUI guy: IntelliJ IDEa with Gradle integratiom -> help
• allowed to use gradle idea -> guide

so,

Q: How to elegant marriage these components. How can I define an init script to be used in the wrapper of a single repository without affecting other repositories.

I know:

• init scripts are typical in a "GRADLE_HOME" directory
• init scripts can be defined per console via -I
  (yes, I read the documentation 😅 )

Problems found:

• intelliJ doesn't allow to define the -I option in UI
• anyone needs to checkout and update a seperate repository if you want to share between projects
• the settings.gradle || gradle.properties file seems not to support any option either

Constraints: (while these are possible answers, they are neither elegant nor fault proof)

• the desired solution should be applicable for SINGLE projects, and should not be globally applied to all projects on the same computer

Hidden Questions:

• can I include global gradle settings from an URL so noone needs a clone of the meta-repo??
• does an URL include do the same as an init script? Or what you can do with initScript what you can't in include?

Vasyuta

Answer 1

You can do the following:

1. Create a custom gradle distribution with the common settings defined in the init script
2. Configure your projects to use that distribution through the distributionUrl key in the gradle/wrapper/gradle-wrapper.properties
3. Use regular gradle build from command line/usual import into intellij - it just works

By the way, there is a gradle plugin for simplifying custom gradle distribution construction

Redouble

unfortunately this seems to be the best of the options - nevertheless it's not that practical due to the fact, that you have an extra asset to maintain plus the fact, that code is typically not in the same repository. Anyway: thanks for the plugin hint! – Talion

Well, all problems in computer science can be solved by another level of abstraction except for the problem of too many layers of abstraction :) I don't quite get your concern about different repositories - you publish custom gradle-dist into a shared location and point to it from gradle-wrapper.properties in all projects – Redouble

my point is: developing 12factor apps includes that any code that belongs to get this project run and deployed is in the same repository so that it is reproducable from scratch anytime ... yes, it's getting esotheric here ;) – Talion

Answer 2

You can use the buildSrc customization - depending on what you need -

where buildSrc/build.gradle takes effect prior configuration phase of your project.

What you should know, that there is a different scope, i.e. buildSrc/build.gradle's allprojects is scoped to any project beneath buildSrc and not your normal projects. More generally speaking: buildSrc/build.gradle is like what you do normally in buildscript or task declarations in script plugins and you can write clean plugin code without publish it as plugins.

⚠️ Limitations:

1. you can't take care about plugin resolution - therefor you have to get into your projects settings.gradle
2. you can't change dependency management for your projects - you still have to do this in your project's buildSrc

for both you can see How can the gradle plugin repository be changed?

3. you still have to apply (even self buildSrc homed) plugins in your project (what is a good thing if you ask me, because it's more visible / clear what happens)
4. you can't share this with a second repository - without using git submodules, etc.

Vasyuta