How to add a class / an enum to settings gradle script on gradle 6.0+?

user_3568191 0
Viewed 318

I want to add an enum called modules with the path of the sub module and some compilation types.

I used to have this in the buildSrc before gradle 6 and it was accessible in the settings.gradle

But from gradle 6.0, settings.gradle is compiled before buildSrc project. I have moved my enum to the settings.gradle, now it is not accessible to other project level gradle scripts.

The behaviour change is outlined in the below release notes. https://docs.gradle.org/current/userguide/upgrading_version_5.html#changes_to_plugins_and_build_scripts

They suggest to add the enums / classes used in the settings.gradle to the build script closure, but I am not really sure how to do that.

https://docs.gradle.org/current/userguide/upgrading_version_5.html#plugins_and_classes_loaded_in_settings_scripts_are_visible_to_project_scripts_and_buildsrc

gradle-kotlin-dsl android-gradle-plugin gradle android
1 Answers

I've recently hit a similar issue, my company have custom code for authenticating with our Nexus which we were keeping in buildSrc. I can't turn this into a plugin since I'd need to store that in our Nexus and then would be in a catch-22 situation as I'd need to authenticate to get the authentication plugin!

I can see 2 potential workarounds for this:

  1. Publicly published jar.

Build your custom classes as a separate jar, or a Gradle plugin if this fits the use case. Publish the jar to a maven repository that you can access from settings.gradle buildscript (for me this is difficult as it's sensitive company specific code).

This might look something like the following in your settings.gradle:

include "project-name"

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
       classpath 'com.companyname:gradle-utils:0.0.1'
    }
}
  1. Commit the binary

This isn't a desirable option but you can manage the source code for your custom buildSrc classes in another repository, then every time you make a change to them (hopefully infrequently) - you can build the new version and commit the built jar into the repositories that need to use it (perhaps under buildSrc). If your custom code has dependencies that aren't naturally on the classpath when gradle runs, you'd need to package these into the jar that you commit as well.

Your settings.gradle might then look like:

include "project-name"

buildscript {
    dependencies {
         classpath files("buildSrc/gradle-utils.jar")
    }
}
user_80692150
Related