KOGE

Parameter Passing

This section explores the different types of options, arguments, properties, and variables in Gradle’s build environment, discussing their differences, overriding relationships, and usage techniques.

CLI Options

The most direct way to pass parameters in Gradle is through Command Line Interface (CLI) options. These options can be grouped into five categories, each extensively covered in the official Gradle documentation:

1. Debugging options
2. Performance options
3. Logging options
4. Execution options
5. Environment options

“CLI Options”@Gradle

After getting a general idea, the following articles can deepen your understanding, focusing on debugging and performance monitoring:

1. “Troubleshooting builds”@Stefan M.
2. “How to debug Gradle Plugins with IntelliJ”@StefanM.

These articles emphasize debugging capabilities for plugins and scripts, noting that script debugging is still evolving.

gradle.properties

Some performance-related switches, in addition to CLI syntax, also correspond to keys in gradle.properties. This file is Gradle’s default location for various environment parameters. Regularly used parameters can be set here to avoid extensive CLI configurations. Its definition and the overriding relationship with CLI parameters are documented as follows:

1. “Gradle properties”@Gradle
2. “Build Environment”@Gradle

gradle.properties includes system properties, environment variables, project properties, and various plugin properties. AGP and Kotlin’s properties can be further explored in these articles:

1. “Configuring Gradle with gradle.properties”@Jean-Michel Fayard
2. “How to Store Credentials in Android Projects Using gradle.properties”@Clint Paul
3. “Dependencies versions in Gradle Kotlin DSL”@Kamil Seweryn

Reading and Using Parameters

The last article from the previous section already shows how to manage dependency versions using gradle.properties. Here, we list some more generic custom parameter inputs and reading methods, focusing on understanding the extra and by project delegation reading methods:

1. “Declaring variables”@Gradle
2. “ext-in-buildscript-can-not-be-recognised-by-gradle-kotlin-dsl”
3. “ExtraPropertiesExtension”@Gradle
4. “Set gradle.ext in settings.gradle.kts with Gradle Kotlin DSL”@Tura
5. “Reference property in Gradle Properties”@Zsolt Boldizsár
6. “kotlin-dsl-samples/samples/extra-properties”@Gradle
7. “kotlin-dsl-samples/samples/project-properties/”@Gradle

Additionally, a common issue arises when using buildscript{} with ext or extra:

• “The execution order of scripts containing buildscript”@2BAB (in Simiplified Chinese)

Summary

• Many of the built-in parameters in Gradle are primarily related to monitoring and debugging. It’s beneficial to practice these debugging methods and tools (like --scan) regularly, especially when encountering build issues. This proactive approach helps in quickly identifying and resolving problems.
• Custom paraeter reading can effectively leverage Kotlin’s delegation features. However, using extra across modules is not always convenient due to the loose coupling nature of keys as strings. In many cases, it’s advisable to utilize buildSrc combined with scripts for sharing data. This method provides a more structured and maintainable approach to managing shared configurations and dependencies across different modules in a Gradle project.

This site is open source. Improve this page.