8

to sum up the components and environment:

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?
childno͡.de
  • 4,679
  • 4
  • 31
  • 57

2 Answers2

4

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

childno͡.de
  • 4,679
  • 4
  • 31
  • 57
denis.zhdanov
  • 3,734
  • 20
  • 25
  • 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! – childno͡.de Oct 31 '18 at 05:41
  • 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 – denis.zhdanov Oct 31 '18 at 13:38
  • 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 ;) – childno͡.de Oct 31 '18 at 14:31
0

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?

  1. 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)
  2. you can't share this with a second repository - without using git submodules, etc.
childno͡.de
  • 4,679
  • 4
  • 31
  • 57