# Component Design Standards for Gradle
This document outlines coding standards specifically for component design in Gradle. It focuses on creating reusable, maintainable, and testable components within Gradle builds. Adhering to these standards improves collaboration, reduces code duplication, and enhances the overall quality of Gradle projects.
## 1. Principles of Component Design in Gradle
### 1.1. Single Responsibility Principle (SRP)
**Standard:** Each component (plugin, task, extension) should have one, and only one, reason to change.
**Why:** SRP enhances maintainability. Changes to one component are less likely to impact others if each component has a well-defined responsibility.
**Do This:**
* Clearly define the scope of each component before implementation.
* Refactor components that perform multiple unrelated tasks into smaller, more focused components.
**Don't Do This:**
* Create "god" components that handle numerous responsibilities.
**Example:**
"""kotlin
// Good: Separate tasks for linting and formatting
tasks.register("detekt") {
// Linting configuration
}
tasks.register("ktlintFormat") {
// Formatting configuration
}
// Bad: A single task that does both linting and formatting
tasks.register("codeQuality") {
doLast {
// Linting logic
// Formatting logic
}
}
"""
### 1.2. Open/Closed Principle (OCP)
**Standard:** Components should be open for extension, but closed for modification.
**Why:** OCP enables adding new functionality without altering existing code, reducing the risk of introducing bugs.
**Do This:**
* Use extension points, interfaces, and abstract classes to allow customization.
* Create customizable tasks through properties and actions.
**Don't Do This:**
* Modify existing component code directly to add new features if there are alternative ways.
**Example:**
"""kotlin
// Good: Use an extension to configure the plugin
open class MyPluginExtension {
var message: String = "Hello, world!"
}
class MyPlugin: Plugin {
override fun apply(project: Project) {
val extension = project.extensions.create("myPlugin", MyPluginExtension::class.java)
project.task("myTask") {
doLast {
println(extension.message)
}
}
}
}
// In build.gradle.kts
plugins {
id("com.example.myplugin")
}
myPlugin {
message = "Custom message!"
}
// Bad: Hardcoding configuration directly in the plugin
class MyPlugin: Plugin {
override fun apply(project: Project) {
project.task("myTask") {
doLast {
println("Hello, world!")
}
}
}
}
"""
### 1.3. Liskov Substitution Principle (LSP)
**Standard:** Subtypes should be substitutable for their base types without altering the correctness of the program.
**Why:** LSP ensures that components can be replaced with their subtypes without causing unexpected behavior.
**Do This:**
* Always ensure subclasses adhere to the contract defined by the superclass.
* Avoid introducing preconditions or postconditions that are stronger than those in the superclass.
**Don't Do This:**
* Create subclasses that throw exceptions in methods inherited from the superclass, unless they are clearly documented as unsupported operations.
**Example:**
"""kotlin
// Good
interface ArtifactPublisher {
fun publish(artifact: File, repositoryUrl: String)
}
class MavenArtifactPublisher : ArtifactPublisher {
override fun publish(artifact: File, repositoryUrl: String) {
// Maven publishing logic
}
}
class IvyArtifactPublisher : ArtifactPublisher {
override fun publish(artifact: File, repositoryUrl: String) {
// Ivy publishing logic
}
}
// Bad: Introducing exception in subclass that breaks LSP
class BrokenArtifactPublisher : ArtifactPublisher {
override fun publish(artifact: File, repositoryUrl: String) {
throw UnsupportedOperationException("This publisher doesn't support remote repositories")
}
}
"""
### 1.4. Interface Segregation Principle (ISP)
**Standard:** Clients should not be forced to depend on methods they do not use.
**Why:** ISP promotes loose coupling and prevents unnecessary dependencies.
**Do This:**
* Break large interfaces into smaller, more specific interfaces.
* Provide default implementations for optional methods in interfaces or abstract classes.
**Don't Do This:**
* Create monolithic interfaces that force clients to implement methods they don't need.
**Example:**
"""kotlin
// Good: Separated interfaces for different functionalities
interface CodeAnalyzer {
fun analyze(file: File)
}
interface CodeFormatter {
fun format(file: File)
}
class MyCodeAnalyzer : CodeAnalyzer {
override fun analyze(file: File) {
// Analysis logic
}
}
class MyCodeFormatter : CodeFormatter {
override fun format(file: File) {
// Formatting logic
}
}
// Bad: A single interface that combines analysis and formatting which might force implementations to provide both even if only one is desired.
interface CodeQualityTool {
fun analyze(file: File)
fun format(file: File)
}
"""
### 1.5. Dependency Inversion Principle (DIP)
**Standard:** High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
**Why:** DIP promotes loose coupling, improves testability, and makes components more reusable.
**Do This:**
* Use interfaces or abstract classes to define dependencies.
* Employ dependency injection to provide concrete implementations at runtime.
**Don't Do This:**
* Create direct dependencies from high-level modules to concrete implementations of low-level modules.
**Example:**
"""kotlin
// Good: Using dependency injection with constructor injection
interface Logger {
fun log(message: String)
}
class ConsoleLogger : Logger {
override fun log(message: String) {
println(message)
}
}
class MyService(private val logger: Logger) {
fun doSomething() {
logger.log("Doing something...")
}
}
// In your Gradle task or plugin:
val logger = ConsoleLogger()
val service = MyService(logger)
service.doSomething()
// Bad: Directly creating a dependency
class MyService {
private val logger = ConsoleLogger()
fun doSomething() {
logger.log("Doing something...")
}
}
"""
## 2. Gradle-Specific Component Design Patterns
### 2.1. Custom Tasks
**Standard:** Use custom tasks for encapsulating specific build logic.
**Why:** Tasks provide a clear and reusable way to define build actions.
**Do This:**
* Extend "DefaultTask" or "JavaExec" for custom task implementations.
* Annotate task inputs and outputs using "@Input", "@OutputDirectory", "@OutputFile", etc. for incrementality.
* Use lazy configuration with "Property" and "Provider" APIs.
**Don't Do This:**
* Put complex logic directly in "build.gradle.kts" files.
* Avoid using the "doLast" and "doFirst" closure configuration style when possible, opting instead for an "Action" object.
**Example:**
"""kotlin
import org.gradle.api.DefaultTask
import org.gradle.api.file.DirectoryProperty
import org.gradle.api.file.RegularFileProperty
import org.gradle.api.tasks.Input
import org.gradle.api.tasks.OutputDirectory
import org.gradle.api.tasks.OutputFile
import org.gradle.api.tasks.TaskAction
import org.gradle.api.provider.Property
abstract class MyCustomTask : DefaultTask() {
@get:Input
abstract val message: Property
@get:OutputDirectory
abstract val outputDir: DirectoryProperty
@get:OutputFile
abstract val outputFile: RegularFileProperty
init {
outputDir.convention(project.layout.buildDirectory.dir("customOutput"))
outputFile.convention(outputDir.file("output.txt"))
}
@TaskAction
fun execute() {
val outputText = "${message.get()} Gradle!"
outputFile.get().asFile.writeText(outputText)
println("Wrote: $outputText to ${outputFile.get()}")
}
}
tasks.register("myCustomTask") {
message.set("Hello")
}
"""
### 2.2. Custom Plugins
**Standard:** Encapsulate reusable build logic into custom plugins.
**Why:** Plugins promote modularity and code reuse across multiple projects.
**Do This:**
* Create plugins using the "Plugin" interface.
* Define extension objects to provide configuration options.
* Apply plugins programmatically using "project.plugins.apply()".
* Publish plugins for wider reuse.
**Don't Do This:**
* Embed plugin logic directly in "build.gradle.kts" files.
* Neglect to apply the 'java-gradle-plugin' in 'java' plugins.
**Example:**
"""kotlin
import org.gradle.api.Plugin
import org.gradle.api.Project
class GreetingPlugin : Plugin {
override fun apply(project: Project) {
val extension = project.extensions.create("greeting", GreetingPluginExtension::class.java)
project.task("greeting") {
doLast {
println("${extension.message.get()} from ${project.name}")
}
}
}
}
open class GreetingPluginExtension {
val message: org.gradle.api.provider.Property = org.gradle.kotlin.dsl.getByType(org.gradle.api.provider.ProviderFactory::class).property(String::class.java).convention("Hello")
}
// In build.gradle.kts:
plugins {
id("com.example.greeting") version "1.0.0"
}
greeting {
message.set("Greetings")
}
"""
### 2.3. Configuration Avoidance
**Standard:** Defer the creation and configuration of tasks until they are actually needed.
**Why:** Configuration avoidance improves build performance, especially for large projects with many tasks. Tasks that are never needed are never configured, saving time.
**Do This:**
* Use "tasks.register(...)" instead of "tasks.create(...)" to register tasks lazily.
* Use the "named(...)" API to configure existing tasks lazily.
* Strongly prefer using providers: "provider { ... }".
**Don't Do This:**
* Instantiate expensive objects and configurations directly inline.
**Example:**
"""kotlin
// Good: Lazy Task Registration and Configuration
tasks.register("copyDocs") {
// Configuration is deferred until the task is needed.
from("src/docs")
into("${buildDir}/docs")
}
// Lazy configuration using named:
tasks.named("test") {
useJUnitPlatform()
}
// Bad: Eager Task Creation
val copyDocs = tasks.create("copyDocs") {
from("src/docs")
into("${buildDir}/docs")
}
"""
### 2.4. Convention over Configuration
**Standard:** Use Gradle's conventions to reduce explicit configuration. Leverage "buildSrc".
**Why:** This simplifies build scripts and makes them easier to understand and maintain.
**Do This:**
* Follow Gradle's directory structure conventions (e.g., "src/main/java", "src/test/java").
* Use the "buildSrc" directory for custom build logic, extensions, and configurations.
**Don't Do This:**
* Override conventions without a clear reason.
* Copy-paste common configuration across multiple build files.
**Example:**
"""kotlin
// Good: Using buildSrc for shared constants
// buildSrc/src/main/kotlin/Libs.kt
object Libs {
const val kotlinVersion = "1.9.22"
const val coroutinesVersion = "1.8.0"
}
// In build.gradle.kts:
dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:${Libs.coroutinesVersion}")
}
// Bad: Hardcoding versions in multiple build files
dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")
}
"""
### 2.5. Extension Objects
**Standard:** Use extension objects to provide configuration options for plugins and tasks.
**Why:** Extensions offer a structured and type-safe way to configure components.
**Do This:**
* Create extension classes using "project.extensions.create()".
* Use properties with lazy configuration via "Property" and "Provider" APIs.
**Don't Do This:**
* Store configuration directly in the task class without an extension.
* Use mutable properties like "var" without considering thread safety.
**Example:**
"""kotlin
// Good: Extension object with lazy configuration
open class MyTaskExtension(objects: ObjectFactory) {
val message: Property = objects.property(String::class.java).convention("Default Message")
}
abstract class MyCustomTask : DefaultTask() {
@get:Input
abstract val message: Property
@TaskAction
fun execute() {
println(message.get())
}
}
class MyPlugin : Plugin {
override fun apply(project: Project) {
val extension = project.extensions.create("myTaskConfig", MyTaskExtension::class.java, project.objects)
val myTask = project.tasks.register("myTask") {
message.set(extension.message)
}
}
}
// In build.gradle.kts
plugins {
id("com.example.myplugin")
}
myTaskConfig {
message.set("Custom Message")
}
// Bad: Direct task configuration without extension
tasks.register("myTask") {
message.set("Custom Message") // No centralized configuration
}
"""
## 3. Advanced Component Design Considerations
### 3.1. Incremental Builds
**Standard:** Design components to support incremental builds.
**Why:** Incremental builds significantly improve build performance by only re-executing tasks with changed inputs.
**Do This:**
* Annotate task inputs and outputs with appropriate properties like "@Input", "@OutputFile", "@InputDirectory", "@InputFiles", and "@Classpath".
* Ensure tasks are cacheable by implementing "org.gradle.workers.WorkAction". Don't use "doLast" or "doFirst" with closures.
* Use "@SkipWhenEmpty" or similar annotations if the task should skip execution when certain inputs are empty or missing.
**Don't Do This:**
* Declare imprecise inputs or outputs, which can cause unnecessary task execution.
* Ignore file timestamps or content changes when determining task up-to-dateness.
**Example:**
"""kotlin
import org.gradle.api.DefaultTask
import org.gradle.api.file.RegularFileProperty
import org.gradle.api.tasks.*
import org.gradle.api.GradleException
abstract class MyTransformTask : DefaultTask() {
@get:InputFile
@get:PathSensitive(PathSensitivity.RELATIVE)
abstract val inputFile: RegularFileProperty
@get:OutputFile
abstract val outputFile: RegularFileProperty
@TaskAction
fun transform() {
val inputFileVal = inputFile.get().asFile
val outputFileVal = outputFile.get().asFile
if (!inputFileVal.exists()) {
throw GradleException("Input file does not exist: ${inputFileVal.absolutePath}")
}
println("Transforming ${inputFileVal.name} to ${outputFileVal.name}")
outputFileVal.writeText(inputFileVal.readText().toUpperCase()) // Example transformation
}
}
tasks.register("transformFile") {
inputFile.set(file("input.txt"))
outputFile.set(file("output.txt"))
}
"""
### 3.2. Worker API
**Standard:** Use the Worker API for parallel execution of tasks.
**Why:** Allows tasks to perform work concurrently, improving build speed, especially for CPU-bound operations (since Gradle 6.0).
**Do This:**
* Use "project.workerExecutor" to submit work to the worker queue.
* Implement "WorkAction" and associated "WorkParameters" interfaces.
* Consider using "IsolationMode.PROCESS" or "IsolationMode.CLASSLOADER" for efficient resource utilization.
**Don't Do This:**
* Perform I/O operations directly in the task action
* Use Thread API's directly.
**Example:**
"""kotlin
import org.gradle.api.file.ConfigurableFileCollection
import org.gradle.api.file.DirectoryProperty
import org.gradle.api.provider.Property
import org.gradle.workers.WorkAction
import org.gradle.workers.WorkParameters
import org.gradle.workers.WorkerExecutor
import javax.inject.Inject
interface MyWorkParameters : WorkParameters {
val inputFile: ConfigurableFileCollection
val outputFile: DirectoryProperty
val message: Property
}
abstract class MyWorkAction @Inject constructor() : WorkAction {
override fun execute() {
parameters.inputFile.forEach { file ->
val outputFile = parameters.outputFile.file(file.name + ".txt").get().asFile
outputFile.writeText("${parameters.message.get()} ${file.readText()}")
}
}
}
abstract class MyWorkerTask @Inject constructor(private val workerExecutor: WorkerExecutor) : DefaultTask() {
@get:InputFiles
abstract val inputFiles: ConfigurableFileCollection
@get:OutputDirectory
abstract val outputDir: DirectoryProperty
@get:Input
abstract val message: Property
@TaskAction
fun run() {
workerExecutor.noIsolation().submit(MyWorkAction::class.java) {
inputFile.from(inputFiles)
outputFile.set(outputDir)
message.set(message)
}
}
}
"""
### 3.3. Task Configuration Avoidance with Providers API
**Standard:** Utilize "Provider" APIs for lazy evaluation and configuration of task properties.
**Why:** Reduces build time by deferring calculations and configurations until absolutely necessary. Enhances incrementality.
**Do This:**
* Declare task properties as "Property" and configure them using "Provider".
* Use "map()", "flatMap()", and "orElse()" methods to transform and combine providers.
* Use "provider { ... }" block to create providers from computations that should be executed only when the value is needed.
**Don't Do This:**
* Access task properties directly with ".get()" during configuration, forcing early evaluation.
**Example:**
"""kotlin
import org.gradle.api.provider.Provider
abstract class MyConfigurableTask : DefaultTask() {
@get:Input
abstract val version: Property
init {
//Example of configuring the value of "version" to use the project's version
version.convention(project.provider { project.version.toString() })
}
@TaskAction
fun execute() {
println("Version: ${version.get()}")
}
}
"""
## 4. Security Considerations
### 4.1. Secrets Management
**Standard:** Avoid hardcoding secrets in build scripts.
**Why:** Prevents accidental exposure of sensitive information
**Do This:**
* Use environment variables or Gradle properties to store secrets.
* Retrieve secrets using "System.getenv()" or "project.properties".
* Consider using a dedicated secrets management tool like HashiCorp Vault.
* Use "buildSrc" to store constants.
**Don't Do This:**
* Commit secrets directly to source control.
* Pass secrets as command-line arguments.
**Example:**
"""kotlin
// Retrieving secret from environment variable
val apiKey = System.getenv("API_KEY") ?: "defaultApiKey"
tasks.register("apiCall") {
doLast {
println("Using API key: $apiKey")
}
}
"""
### 4.2. Dependency Management
**Standard:** Manage dependencies securely.
**Why:** Mitigates risks associated with vulnerable dependencies.
**Do This:**
* Use dependency management features like BOMs (Bill of Materials) to ensure consistent versions.
* Use dependency verification to ensure that artifacts come from trusted sources.
* Employ dependency scanning tools (e.g., OWASP Dependency-Check) to identify vulnerabilities.
* Regularly update dependencies to the latest secure versions.
**Don't Do This:**
* Use wildcard versions (e.g., "1.+").
* Ignore security vulnerabilities reported by dependency scanning tools.
**Example:**
"""kotlin
dependencies {
implementation(platform("org.springframework.boot:spring-boot-dependencies:3.3.0")) // Use BOM
implementation("org.springframework.boot:spring-web") // Explicitly declaring the library uses the BOM version.
constraints {
implementation("org.apache.logging.log4j:log4j-core") {
version {
strictly("[2.22.1]") // Specify version in a security constraint
}
because("Addresses CVE-2024-27958")
}
}
}
"""
## 5. Conclusion
These coding standards for component design in Gradle provide a foundation for creating high-quality, maintainable, and secure builds. Adhering to these principles and best practices will improve team collaboration, reduce technical debt, and enhance the overall success of Gradle projects. Regularly review and update these standards to incorporate new Gradle features and evolving best practices.
danielsogl
Created Mar 6, 2025
This guide explains how to effectively use .clinerules with Cline, the AI-powered coding assistant.
The .clinerules file is a powerful configuration file that helps Cline understand your project's requirements, coding standards, and constraints. When placed in your project's root directory, it automatically guides Cline's behavior and ensures consistency across your codebase.
Place the .clinerules file in your project's root directory. Cline automatically detects and follows these rules for all files within the project.
# Project Overview project: name: 'Your Project Name' description: 'Brief project description' stack: - technology: 'Framework/Language' version: 'X.Y.Z' - technology: 'Database' version: 'X.Y.Z'
# Code Standards standards: style: - 'Use consistent indentation (2 spaces)' - 'Follow language-specific naming conventions' documentation: - 'Include JSDoc comments for all functions' - 'Maintain up-to-date README files' testing: - 'Write unit tests for all new features' - 'Maintain minimum 80% code coverage'
# Security Guidelines security: authentication: - 'Implement proper token validation' - 'Use environment variables for secrets' dataProtection: - 'Sanitize all user inputs' - 'Implement proper error handling'
Be Specific
Maintain Organization
Regular Updates
# Common Patterns Example patterns: components: - pattern: 'Use functional components by default' - pattern: 'Implement error boundaries for component trees' stateManagement: - pattern: 'Use React Query for server state' - pattern: 'Implement proper loading states'
Commit the Rules
.clinerules in version controlTeam Collaboration
Rules Not Being Applied
Conflicting Rules
Performance Considerations
# Basic .clinerules Example project: name: 'Web Application' type: 'Next.js Frontend' standards: - 'Use TypeScript for all new code' - 'Follow React best practices' - 'Implement proper error handling' testing: unit: - 'Jest for unit tests' - 'React Testing Library for components' e2e: - 'Cypress for end-to-end testing' documentation: required: - 'README.md in each major directory' - 'JSDoc comments for public APIs' - 'Changelog updates for all changes'
# Advanced .clinerules Example project: name: 'Enterprise Application' compliance: - 'GDPR requirements' - 'WCAG 2.1 AA accessibility' architecture: patterns: - 'Clean Architecture principles' - 'Domain-Driven Design concepts' security: requirements: - 'OAuth 2.0 authentication' - 'Rate limiting on all APIs' - 'Input validation with Zod'
# State Management Standards for Gradle This document outlines the coding standards for managing state within Gradle builds and plugins. Effective state management is crucial for creating reliable, reproducible, and maintainable builds. It specifically addresses how Gradle projects and plugins should handle data that persists across tasks or configurations. ## 1. Principles of State Management in Gradle Managing state in Gradle is significantly different from managing state in a typical application. Gradle's build system is designed to be declarative and (ideally) idempotent. Therefore, state should be managed with these goals in mind. * **Immutability:** Favor immutable data structures. This prevents accidental modifications and simplifies reasoning about the build process. * **Reproducibility:** Strive to make builds reproducible. This means that, given the same input state, the build should produce the same output. Avoid relying on external state that can change unexpectedly. * **Explicit Dependencies:** Declare dependencies explicitly. Gradle's dependency management system is powerful; use it to your advantage. * **Avoid Global State:** Minimize the use of global state in your build scripts and plugins. Global state can lead to unexpected side effects and make builds difficult to reason about. * **Task Inputs and Outputs:** Use task inputs and outputs to track and manage the state of individual tasks. Gradle uses this information to determine whether a task needs to be executed. * **Configuration Cache Compatibility:** Design your build scripts and plugins to be compatible with Gradle's Configuration Cache feature. This requires careful consideration of state management. * **Incremental Build Support:** Design your tasks to support incremental builds by properly defining inputs and outputs. ## 2. Configuration Phase State Management The configuration phase in Gradle involves evaluating the "build.gradle.kts" script and associated plugins. State managed during this phase impacts how the build is configured. ### 2.1. Project Properties and Extensions Project properties and extra properties are mechanisms for storing state that can be accessed throughout the build script. Extensions provide a structured way to encapsulate related properties. **Do This:** * Use project extensions to group related properties, providing a clear structure for your build configuration. * Define extensions within plugins to encapsulate build logic and configuration. * Use "providers" for properties where the value may not be known at configuration time. Providers allow for lazy evaluation. * Prefer Kotlin DSL's typed accessors for safer and more readable property access. **Don't Do This:** * Don't pollute the global namespace with too many project-level properties. This can lead to naming conflicts and make it difficult to understand the build configuration. * Don't store complex objects directly in project properties. Use extensions to encapsulate object logic. * Don't eagerly calculate property values if they aren't immediately needed. **Example:** """kotlin // build.gradle.kts plugins { id("org.example.my-plugin") } myPlugin { apiEndpoint.set("https://api.example.com") timeoutSeconds.set(30) } tasks.register("printConfig") { doLast { println("API Endpoint: ${myPlugin.get().apiEndpoint.get()}") println("Timeout: ${myPlugin.get().timeoutSeconds.get()}") } } // src/main/kotlin/org/example/MyPlugin.kt package org.example import org.gradle.api.Plugin import org.gradle.api.Project import org.gradle.api.provider.Property import org.gradle.kotlin.dsl.* interface MyPluginExtension { val apiEndpoint: Property<String> val timeoutSeconds: Property<Int> } class MyPlugin : Plugin<Project> { override fun apply(project: Project) { val extension = project.extensions.create<MyPluginExtension>("myPlugin") { apiEndpoint.convention("https://default.example.com") timeoutSeconds.convention(60) } } } """ **Explanation:** * The "MyPluginExtension" interface defines the properties for the plugin. * The "apiEndpoint" and "timeoutSeconds" properties are defined as "Property<String>" and "Property<Int>" respectively, allowing users to configure them in the "build.gradle.kts" file. * The "convention" method sets default values for the properties. * Kotlin DSL accessors are used. The generated accessor for the created extension allows the plugin user to access the "myPlugin" extension in a type-safe way. * Lazy evaluation is used through ".get()", so values are only fetched when needed. ### 2.2. Configuration Cache Considerations The Configuration Cache is a performance optimization that caches the result of the configuration phase. To support it, you must ensure that your configuration logic is serializable and doesn't rely on external state that can change between builds. **Do This:** * Ensure that all objects stored in project properties or extensions are serializable. Prefer simple data types like String, Int, and Boolean. If using complex objects, implement "java.io.Serializable" or, even better, use Gradle's "BuildService" API with injected state. * Use "providers" to defer the reading of external state (e.g., environment variables) until task execution. * Avoid using non-serializable classes or objects within your plugins. * Annotate non-serializable fields with "@Transient" if absolutely necessary. However, try to avoid this. **Don't Do This:** * Don't store non-serializable objects in project properties or extensions without careful consideration. * Don't read environment variables or system properties directly during the configuration phase. * Don't use singleton objects with mutable state within your build configuration logic. **Example:** """kotlin // build.gradle.kts plugins { id("org.example.config-cache-plugin") } the<ConfigCacheExtension>().apply { message.set("Hello, Configuration Cache!") } tasks.register("configCacheTask") { doLast { println(the<ConfigCacheExtension>().message.get()) } } // src/main/kotlin/org/example/ConfigCachePlugin.kt package org.example import org.gradle.api.Plugin import org.gradle.api.Project import org.gradle.api.provider.Property import org.gradle.kotlin.dsl.create import org.gradle.kotlin.dsl.the interface ConfigCacheExtension { val message: Property<String> } class ConfigCachePlugin : Plugin<Project> { override fun apply(project: Project) { project.extensions.create<ConfigCacheExtension>("configCacheExtension") { message.convention("Default message") } } } """ **Explanation:** * The "ConfigCacheExtension" interface defines a single "message" property of type "Property<String>". * The "message" property is configured with a default value using the "convention" method. * A task "configCacheTask" is registered to print the value of the "message" property at execution time. Crucially, the property value is not accessed during the configuration phase. ## 3. Task Phase State Management Tasks are the fundamental units of execution in Gradle. Managing task state involves defining inputs, outputs, and actions that modify the build environment. ### 3.1. Task Inputs and Outputs Task inputs define the data that a task consumes, while task outputs define the data that a task produces. Gradle uses this information to determine whether a task needs to be executed. **Do This:** * Declare all task inputs and outputs explicitly using the "@Input", "@OutputDirectory", "@OutputFile", "@InputFile", "@InputFiles", "@InputDirectory", "@Classpath", "@Optional", and "@Console" annotations (or their equivalent DSL methods). * Use "incrementalTaskInput" for tasks that can process only changed input files. * Use property annotations like "@Input", "@Optional", and "@InputDirectory" along with abstract classes and "abstract val" to define task inputs in a type-safe way. * Use Gradle's built-in file system operations for managing task outputs to ensure consistency and correctness. * Use "TaskProvider" when declaring task dependencies to allow for lazy configuration. * Use the "up-to-date checks" functionality to avoid unnecessary task executions. * Use "@Internal" for properties that represent internal state of the task and should not be considered for up-to-date checks. **Don't Do This:** * Don't assume that a task will always be executed. Gradle may skip task execution if the inputs and outputs haven't changed. * Don't rely on implicit task dependencies. Declare dependencies explicitly using "dependsOn". * Don't modify files outside of the declared task outputs. This can lead to unexpected side effects and make builds unreliable. **Example:** """kotlin import org.gradle.api.DefaultTask import org.gradle.api.file.DirectoryProperty import org.gradle.api.file.RegularFileProperty import org.gradle.api.model.ObjectFactory import org.gradle.api.provider.Property import org.gradle.api.tasks.* import javax.inject.Inject abstract class MyTask @Inject constructor(objects: ObjectFactory) : DefaultTask() { @get:Input abstract val message: Property<String> @get:InputFile @get:PathSensitive(PathSensitivity.RELATIVE) abstract val inputFile: RegularFileProperty @get:OutputDirectory abstract val outputDir: DirectoryProperty @TaskAction fun run() { val inputFilePath = inputFile.get().asFile.absolutePath val outputDirPath = outputDir.get().asFile.absolutePath val messageValue = message.get() // Simulate processing the input file and writing to the output directory val outputFile = outputDir.get().file("output.txt").asFile outputFile.writeText("Message: $messageValue\nInput File: $inputFilePath") println("Task executed: $name") println("Message: $messageValue") println("Input File: $inputFilePath") println("Output File: $outputFile") } } // build.gradle.kts tasks.register<MyTask>("myTask") { message.set("Hello from MyTask!") inputFile.set(file("input.txt")) outputDir.set(file("output")) } """ **Explanation:** * The "MyTask" class extends "DefaultTask" and defines several input and output properties. * The "@Input" annotation declares the "message" property as an input to the task. * The "@InputFile" and "@OutputDirectory" annotations declare the "inputFile" and "outputDir" properties as file inputs and directory outputs, respectively. * The "@PathSensitive(PathSensitivity.RELATIVE)" annotation specifies that the task should be considered out-of-date if the relative path of the input file changes. * The "run" method performs the task's action, reading the input file, processing it, and writing the output to the output directory. This demonstrates how to access the values of inputs and outputs defined as properties. * The "objects: ObjectFactory" is required for property injection into the abstract class. * The build script registers an instance of "MyTask" using "tasks.register<MyTask>("myTask")" ### 3.2. Incremental Tasks Incremental tasks are tasks that can process only the changed input files, rather than reprocessing all input files. This can significantly improve build performance. **Do This:** * Use the "incrementalTaskInput" method to define incremental task inputs. * Use "InputChanges" to determine which inputs have changed since the last task execution. * Use appropriate mechanisms (e.g., file hashing, timestamps) to track changes to input files. **Don't Do This:** * Don't reprocess all input files if only a subset of files has changed. * Don't rely on external state to determine which files have changed. **Example:** """kotlin import org.gradle.api.DefaultTask import org.gradle.api.tasks.* import org.gradle.api.file.FileCollection import org.gradle.api.provider.Property import javax.inject.Inject import org.gradle.api.model.ObjectFactory import org.gradle.api.tasks.incremental.IncrementalTaskInputs abstract class IncrementalCopyTask @Inject constructor(objects: ObjectFactory) : DefaultTask() { @get:InputDirectory abstract val sourceDir: Property<File> @get:OutputDirectory abstract val targetDir: Property<File> @TaskAction fun copyFiles(inputChanges: IncrementalTaskInputs) { if (!inputChanges.isIncremental) { println("Performing full copy as task input is not incremental") targetDir.get().asFile.deleteRecursively() } inputChanges.outOfDate { change -> val sourceFile = change.file val targetFile = targetDir.get().file(change.path).asFile println("Copying ${sourceFile.name} to ${targetFile.path}") sourceFile.copyTo(targetFile, overwrite = true) } inputChanges.removed { change -> val targetFile = targetDir.get().file(change.path).asFile println("Deleting ${targetFile.path}") targetFile.delete() } } } // build.gradle.kts tasks.register<IncrementalCopyTask>("incrementalCopy") { sourceDir.set(file("src/main/resources")) targetDir.set(file("build/resources/main")) } """ **Explanation:** * This task incrementally copies files from a source directory to a target directory. * "IncrementalTaskInputs" is used to determine which files have been added, removed, or modified since the last execution * "inputChanges.isIncremental" allows the task to do optimized processing when running incrementally. * The injected "ObjectFactory" is used to create the "Property" instances. ### 3.3. Build Services Build services are a mechanism for sharing state between tasks and across builds. They are particularly useful for managing resources that are expensive to create or for sharing data between tasks that are not directly related. They are also configuration cache compatible. **Do This:** * Use build services to manage shared resources, such as database connections or API clients. * Define build services as abstract classes or interfaces and register them using "gradle.sharedServices". * Use the "@Inject" annotation to inject build services into tasks. * Consider using "AutoCloseable" to manage the lifecycle of resources held by build services. **Don't Do This:** * Don't use global variables or static fields to share state between tasks. * Don't create build services that are not properly configured or initialized. * Don't forget to release resources held by build services when they are no longer needed. **Example:** """kotlin import org.gradle.api.provider.Property import org.gradle.api.services.BuildService import org.gradle.api.services.BuildServiceParameters import org.gradle.api.tasks.TaskAction import org.gradle.api.DefaultTask import org.gradle.api.tasks.Input import org.gradle.api.Project import org.gradle.api.provider.Provider import org.gradle.kotlin.dsl.* import javax.inject.Inject import org.gradle.api.model.ObjectFactory interface MyBuildServiceParameters : BuildServiceParameters { val message: Property<String> } abstract class MyBuildService @Inject constructor(objects: ObjectFactory): BuildService<MyBuildServiceParameters>, AutoCloseable { private val id = System.identityHashCode(this) init { parameters.message.convention("Default message from service $id") println("Build service $id created with message: ${parameters.message.get()}") } fun doSomething(): String { return "Build service $id says: ${parameters.message.get()}" } override fun close() { println("Build service $id is closing") } } abstract class MyTask @Inject constructor(objects : ObjectFactory): DefaultTask() { @get:Input abstract val taskMessage: Property<String> @TaskAction fun run() { val serviceProvider: Provider<MyBuildService> = project.gradle.sharedServices.registerIfAbsent("my-service", MyBuildService::class) { parameters { message.set(taskMessage) } } val service = serviceProvider.get() println("Task '${name}' executed. " + service.doSomething()) } } // build.gradle.kts gradle.sharedServices.registerIfAbsent("my-shared-service", MyBuildService::class) { parameters { message.set("Message from build.gradle.kts") } } tasks.register<MyTask>("myTask") { taskMessage.set("Hello from MyTask config!") } """ **Explanation:** * The "MyBuildService" class implements the "BuildService" interface and defines a single "message" parameter. * The "MyTask" class uses the "gradle.sharedServices" method to register the "MyBuildService" and obtain a provider for it. * The "run" method obtains an instance of the "MyBuildService" from the provider and uses it to perform some work. * The "AutoCloseable" interface is implemented to release resources when the build service is no longer needed. Gradle will automatically call the "close()" method when the build service is no longer in use, even if the build fails. ### 3.4 Task Dependencies and Ordering Task dependencies define the order in which tasks are executed. Proper management of task dependencies is essential for ensuring that tasks are executed in the correct order and that the build process is efficient. **Do This:** * Declare task dependencies explicitly using the "dependsOn" method. * Use "mustRunAfter" and "shouldRunAfter" to specify ordering constraints between tasks. * Use "TaskProvider"s when specifying task dependencies to allow for lazy configuration. * Leverage Gradle's task ordering features to optimize build performance and ensure correctness. **Don't Do This:** * Don't rely on implicit task dependencies. * Don't create circular task dependencies. * Don't create overly complex task dependency graphs. **Example:** """kotlin // build.gradle.kts val taskA = tasks.register("taskA") { doLast { println("Executing taskA") } } val taskB = tasks.register("taskB") { dependsOn(taskA) doLast { println("Executing taskB") } } tasks.register("taskC") { mustRunAfter(taskB) doLast { println("Executing taskC") } } tasks.register("taskD") { shouldRunAfter(taskC) doLast { println("Executing taskD") } } """ **Explanation:** * "taskB" depends on "taskA", meaning that "taskA" will be executed before "taskB". * "taskC" *must* run after "taskB". * "taskD" *should* run after "taskC". This is a weaker constraint than "mustRunAfter" and allows Gradle to potentially execute "taskC" and "taskD" in parallel if possible. ## 4. Security Considerations When managing state in Gradle, it's important to consider security implications. Build scripts and plugins can access sensitive information, such as API keys, passwords, and certificates. You must protect this information from unauthorized access. **Do This:** * Use environment variables or Gradle properties to store sensitive information. * Avoid hardcoding sensitive information in build scripts or plugins. * Use build scans to track the state of your builds and identify potential security vulnerabilities. * Use secure communication protocols (e.g., HTTPS) when accessing external resources. * Follow secure coding practices when developing Gradle plugins. **Don't Do This:** * Don't store sensitive information in version control. * Don't expose sensitive information in error messages or logs. * Don't use insecure communication protocols (e.g., HTTP) when accessing external resources. * Don't trust external code without proper validation. **Example:** """kotlin // build.gradle.kts tasks.register("secureTask") { val apiKey = providers.environmentVariable("API_KEY").orElse(providers.gradleProperty("apiKey")).get() doLast { println("Using API key: $apiKey") // In real code, don't print the key! Use it securely. } } """ **Explanation:** * The "secureTask" task retrieves the API key from an environment variable or a Gradle property. * The "environmentVariable" and "gradleProperty" methods provide a secure way to access sensitive information. "orElse" specifies a fallback if the environment variable is not set. * **Important:** In real code, you should *never* print the API key to the console. This is just an example to show how to retrieve it. Instead, use the API key securely within the task. ## 5. Modern Approaches and Patterns Gradle development continuosly evolves. Here are some modern best-practices that should be followed: * Using dependency injection and Providers for lazy evaluation of properties. * Creating custom Gradle managed entities to store global state across the build. * Leveraging Build Scans to view global state of the Gradle build. ## 6. Deprecated Features and Known Issues * The "ext" block in Gradle is considered legacy. While it still works, prefer "extensions" for better structure and type safety, particularly with Kotlin DSL. * The Settings API in Gradle is under active development. Breaking changes can sometimes occur between minor releases. Refer to the release notes for each Gradle version to stay informed. * Avoid using the "allprojects" and "subprojects" blocks in favor of more explicit configuration of the projects to apply a certain configuration.
# Deployment and DevOps Standards for Gradle This document outlines the standards and best practices for Deployment and DevOps when using Gradle. It focuses on ensuring maintainable, performant, and secure builds, CI/CD pipelines, and production deployments. ## 1. Build Process and Automation ### 1.1 Standardized Build Scripts **Standard:** Use consistent and repeatable build scripts across all projects. **Do This:** * Externalize common build logic using custom plugins or buildSrc. * Use declarative syntax for build configurations. * Adopt a consistent naming convention for tasks and properties. **Don't Do This:** * Hardcode environment-specific configurations directly into build scripts. * Duplicate build logic across multiple projects. * Use imperative scripting excessively within build files. **Why:** Consistent build scripts improve understanding, simplify maintenance, and reduce errors. Externalizing logic promotes reusability and reduces redundancy. **Example:** """gradle // buildSrc/src/main/java/ExamplePlugin.java import org.gradle.api.Plugin; import org.gradle.api.Project; public class ExamplePlugin implements Plugin<Project> { @Override public void apply(Project project) { project.task("customTask", task -> { task.doLast(t -> System.out.println("Custom Task Executed")); }); } } """ """gradle // build.gradle.kts plugins { id("java") id("example-plugin") // Applies the custom plugin. } tasks.named("customTask") { //Configuration options for custom task. } """ ### 1.2 Dependency Management **Standard:** Utilize Gradle's dependency management features effectively. **Do This:** * Declare dependencies using "implementation", "api", "compileOnly", and "runtimeOnly" configurations, mirroring the scope. * Use version catalogs to centralize dependency versions. * Implement dependency locking for reproducible builds. * Regularly update dependencies, addressing security vulnerabilities. **Don't Do This:** * Rely on transitive dependencies without explicit declarations. * Mix different ways of declaring dependency versions (hardcoded strings, variables, etc). * Ignore dependency updates for extended periods. **Why:** Proper dependency management enhances build reproducibility, security, and performance. **Example:** """gradle // settings.gradle.kts dependencyResolutionManagement { versionCatalogs { create("libs") { version("springBoot", "3.2.0") library("springWeb", "org.springframework.boot", "spring-boot-starter-web").versionRef("springBoot") library("lombok", "org.projectlombok", "lombok").version("1.18.30") bundle("spring", "springWeb", "lombok") //Creating a bundle to group related items. alias("jacksonDatabind").to("com.fasterxml.jackson.core", "jackson-databind").version("2.16.1") } } } """ """gradle // build.gradle.kts dependencies { implementation(libs.bundles.spring) implementation(libs.jacksonDatabind) annotationProcessor(libs.lombok) } """ ### 1.3 Task Configuration and Execution **Standard:** Optimize task configurations for performance and maintainability. **Do This:** * Use Gradle's task avoidance features (e.g., "up-to-date checks", "outputs.upToDateWhen"). * Configure tasks lazily to defer execution until necessary. * Leverage Gradle's configuration cache to speed up build times. * Use incremental builds when possible. **Don't Do This:** * Execute unnecessary tasks. * Block task execution on slow or unreliable resources. * Invalidate task caches unnecessarily. **Why:** Efficient task management minimizes build execution time and improves developer productivity. **Example:** """gradle // build.gradle.kts tasks.register("processFiles") { inputs.dir("src/main/resources") outputs.dir("$buildDir/processedResources") outputs.upToDateWhen { false } // Forces the task to always run, useful for testing outputs.doNotTrackState("Reason for not tracking state") //Avoids tracking state changes. doLast { // Process files from input dir and output them to output dir file("src/main/resources").listFiles()?.forEach { file -> file.copyTo(file("$buildDir/processedResources/${file.name}")) } } } """ ### 1.4 Build Outputs and Artifact Management **Standard:** Manage build outputs and artifacts systematically. **Do This:** * Use Gradle's built-in artifact publishing mechanisms. * Configure repositories correctly (e.g., Maven Central, Artifactory, Nexus). * Use semantic versioning (SemVer) for all artifacts. * Sign artifacts for integrity and authenticity. **Don't Do This:** * Manually copy or upload artifacts. * Use unclear or ambiguous artifact names. * Skip artifact signature verification. **Why:** Consistent artifact management ensures reliable deployments and simplifies dependency resolution. **Example:** """gradle // build.gradle.kts plugins { "maven-publish" } group = "com.example" version = "1.0.0" publishing { repositories { maven { name = "MyRepo" url = uri("https://myrepo.example.com/maven") credentials { username = "user" password = "password" } } } publications { create<MavenPublication>("release") { from(components["java"]) pom { name.set("Example Library") description.set("A simple example library") url.set("http://example.com") licenses { license { name.set("MIT License") url.set("https://opensource.org/licenses/MIT") } } developers { developer { id.set("johndoe") name.set("John Doe") email.set("john.doe@example.com") } } scm { connection.set("scm:git:git://example.com/example.git") developerConnection.set("scm:git:ssh://example.com@example.git") url.set("http://example.com/example") } } } } } signing { sign(publishing.publications["release"]) } """ ## 2. CI/CD Integration ### 2.1 Pipeline Configuration **Standard:** Define CI/CD pipelines using infrastructure-as-code (IaC) principles. **Do This:** * Use tools like Jenkins, GitLab CI, GitHub Actions, or CircleCI. * Externalize pipeline configurations into version-controlled files (e.g., "Jenkinsfile", ".gitlab-ci.yml"). * Define stages for build, test, analyze, and deploy. **Don't Do This:** * Manually configure CI/CD pipelines via UI. * Store sensitive credentials directly in pipeline configurations. * Skip automated tests in CI pipelines. **Why:** IaC ensures that pipelines are repeatable, auditable, and easily reproducible. **Example (GitHub Actions):** """yaml # .github/workflows/gradle.yml name: Gradle Build on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up JDK 17 uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: Gradle Build uses: gradle/gradle-build-action@v2 with: arguments: build - name: Upload Artifacts uses: actions/upload-artifact@v3 with: name: Build Artifacts path: build/libs/ """ ### 2.2 Automated Testing **Standard:** Integrate automated testing into the CI/CD pipeline. **Do This:** * Run unit, integration, and end-to-end tests. * Configure Gradle to execute tests automatically during the build process (using "test" task). * Collect code coverage metrics. * Fail the build if tests fail. **Don't Do This:** * Rely solely on manual testing. * Ignore test failures in CI pipelines. * Skip code coverage analysis. **Why:** Automated testing ensures code quality, reduces regressions, and facilitates faster feedback loops. **Example:** """gradle // build.gradle.kts dependencies { testImplementation("org.junit.jupiter:junit-jupiter-api:5.10.1") testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.10.1") } tasks.test { useJUnitPlatform() testLogging { events("passed", "skipped", "failed") //shows only particular events during test execution. exceptionFormat = org.gradle.api.tasks.testing.logging.TestExceptionFormat.FULL //Verbose output. showStandardStreams = true //Shows the output of Standard output and Standard error streams. } } //Configure Jacoco code coverage by applying a plugin and configuring task. plugins { jacoco } tasks.jacocoTestReport { dependsOn(tasks.test) //Test metrics should be generated after the "Test task" reports { xml.required.set(true) } } """ ### 2.3 Code Analysis **Standard:** Perform static code analysis and security scanning in the CI/CD pipeline. **Do This:** * Integrate tools like SonarQube, Checkstyle, FindBugs, or SpotBugs. * Configure Gradle to execute code analysis tasks. * Set quality gates to enforce coding standards. * Scan dependencies for known vulnerabilities using tools like OWASP Dependency-Check or Snyk. **Don't Do This:** * Ignore code quality issues identified by static analysis tools. * Deploy code with known security vulnerabilities. **Why:** Code analysis helps identify potential bugs, security vulnerabilities, and coding standard violations early in the development cycle. **Example (Using SonarQube):** """gradle plugins { id("org.sonarqube") version "4.4.1.3373" } sonarqube { properties { property("sonar.projectKey", "your-project-key") //Sonarcloud project key property("sonar.organization", "your-organization-key") //Sonarcloud Organization Key property("sonar.host.url", "https://sonarcloud.io") //Url to access sonar cloud. } } tasks.sonarqube { dependsOn(tasks.test) // Code analysis will run once the tests are executed. } """ ### 2.4 Deployment Strategies **Standard:** Implement robust deployment strategies for different environments. **Do This:** * Use techniques like blue-green deployments, canary releases, or rolling updates. * Automate deployment tasks using tools like Ansible, Chef, Puppet, or Kubernetes. * Implement rollback mechanisms in case of deployment failures. **Don't Do This:** * Perform manual deployments to production. * Skip deployment testing in staging environments. * Lack a rollback strategy. **Why:** Robust deployment strategies minimize downtime, reduce risk, and facilitate continuous delivery. **Example (Deploying to Kubernetes):** (Illustrative example, specific steps depend on your Kubernetes setup) """gradle // build.gradle.kts tasks.register("deployToK8s") { dependsOn("build") //Runs after the "build" task has been executed. doLast { // Use kubectl to apply deployment configurations exec { commandLine("kubectl", "apply", "-f", "kubernetes/deployment.yaml") } } } """ ## 3. Production Considerations ### 3.1 Configuration Management **Standard:** Externalize application configurations and manage them centrally. **Do This:** * Use environment variables, configuration files, or centralized configuration services (e.g., Spring Cloud Config, HashiCorp Vault). * Separate configuration from code. * Use different configurations for different environments (e.g., dev, staging, production). **Don't Do This:** * Hardcode configurations directly in the application code. * Store sensitive credentials in version control. **Why:** Externalized configuration simplifies management, improves security, and allows for easier environment-specific adjustments. **Example:** """kotlin // Accessing environment variables in the application fun main() { val databaseUrl = System.getenv("DATABASE_URL") ?: "default_value" println("Database URL: $databaseUrl") } """ ### 3.2 Logging and Monitoring **Standard:** Implement comprehensive logging and monitoring. **Do This:** * Use structured logging formats (e.g., JSON) for easy parsing. * Log relevant application events and errors. * Monitor application performance metrics (e.g., response time, CPU usage, memory usage). * Use tools like Prometheus, Grafana, ELK stack (Elasticsearch, Logstash, Kibana), or Datadog. **Don't Do This:** * Log sensitive information. * Rely solely on console logging. * Ignore application performance alerts. **Why:** Logging and monitoring provide valuable insights into application behavior, performance, and potential issues. **Example:** """kotlin import org.slf4j.LoggerFactory class MyService { private val logger = LoggerFactory.getLogger(MyService::class.java) fun doSomething(input: String) { logger.info("Processing input: {}", input) try { // Some operation } catch (e: Exception) { logger.error("Error processing input: {}", input, e) throw e } } } """ ### 3.3 Security Best Practices **Standard:** Implement security best practices throughout the development and deployment lifecycle. **Do This:** * Follow secure coding practices (e.g., input validation, output encoding, authentication, authorization). * Regularly update dependencies to address security vulnerabilities. * Use HTTPS for all communication. * Implement proper authentication and authorization mechanisms. * Store sensitive data securely (e.g., using encryption). **Don't Do This:** * Ignore security vulnerabilities. * Store passwords in plain text. * Expose sensitive data to unauthorized users. **Why:** Security is paramount for protecting application data and preventing unauthorized access. ### 3.4 Performance Optimization **Standard:** Optimize applications for performance and scalability. **Do This:** * Profile application performance to identify bottlenecks. * Optimize database queries. * Use caching mechanisms (e.g., in-memory cache, CDN). * Implement load balancing. * Monitor resource utilization. **Don't Do This:** * Ignore performance issues. * Premature optimization. **Why:** Performance optimization ensures that applications can handle increasing loads and provide a responsive user experience. ### 3.5 Rollback Strategies **Standard:** Implement comprehensive rollback strategies. **Do This:** * Have a clear rollback plan in case of deployment failures. * Automate the rollback process as much as possible. * Test rollback procedures regularly. * Use feature flags to enable/disable features without requiring a full redeployment. **Don't Do This:** * Lack a rollback plan. * Rely on manual rollback procedures. **Why:** Rollback strategies minimize the impact of deployment failures and ensure business continuity. Feature flags allow for controlled rollouts and easy rollback of specific features. By following these standards, development teams can create robust, maintainable, and secure Gradle builds and deployments. These guidelines are intended to be a living document and should be updated as new technologies and best practices emerge.
# Testing Methodologies Standards for Gradle This document outlines the testing methodologies standards for Gradle projects. Following these standards will lead to more reliable, maintainable, and performant builds. It covers unit, integration, and end-to-end testing strategies, specifically within the context of Gradle. ## 1. General Testing Principles ### 1.1. Test-Driven Development (TDD) * **Do This:** Embrace TDD by writing tests *before* implementing the actual code. This helps clarify requirements, reduces bugs, and leads to better design. * **Don't Do This:** Write tests as an afterthought or skip them altogether. This increases the risk of bugs and makes refactoring harder. * **Why:** TDD ensures that the code is testable from the start, leading to better code coverage and reduced technical debt. ### 1.2. Test Pyramid * **Do This:** Follow the Test Pyramid, with a large base of unit tests, a smaller layer of integration tests, and a very small number of end-to-end (E2E) tests. * **Don't Do This:** Rely heavily on E2E tests at the expense of unit and integration tests. E2E tests are slow and brittle. * **Why:** The Test Pyramid ensures a balanced testing strategy, optimizing for speed, cost, and coverage. Unit tests provide fast feedback, integration tests verify interactions, and E2E tests validate the system as a whole. ### 1.3. Test Coverage * **Do This:** Aim for high test coverage (e.g., 80% or higher) but focus on meaningful tests that cover critical functionality and edge cases. * **Don't Do This:** Strive for 100% coverage without considering the quality of the tests. Coverage is a metric, not a goal in itself. * **Why:** Test coverage provides a measure of how much of the codebase is covered by tests. High coverage, combined with well-written tests, increases confidence in the code's correctness. ### 1.4. Test Independence * **Do This:** Ensure that tests are independent of each other. Each test should set up its own environment and tear it down afterward. * **Don't Do This:** Allow tests to depend on the state left by previous tests. This can lead to flaky tests and make debugging difficult. * **Why:** Independent tests make it easier to reason about individual tests, reduce the risk of cascading failures, and allow tests to be run in parallel. ### 1.5. Clear Assertions * **Do This:** Write clear and specific assertions that clearly state what is being tested. Use descriptive error messages when assertions fail. * **Don't Do This:** Use generic assertions or assertions that are difficult to understand. This makes it harder to diagnose the cause of test failures. * **Why:** Clear assertions make it easier to understand the purpose of each test and to quickly identify the source of errors. ## 2. Unit Testing with Gradle ### 2.1. Using JUnit and Mockito * **Do This:** Use JUnit 5 as the standard unit testing framework and Mockito for mocking dependencies. """gradle dependencies { testImplementation("org.junit.jupiter:junit-jupiter-api:5.11.0-M1") testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.11.0-M1") testImplementation("org.mockito:mockito-core:5.11.0") testImplementation("org.mockito:mockito-junit-jupiter:5.11.0") } test { useJUnitPlatform() } """ * **Don't Do This:** Rely on older versions of JUnit or use custom mocking frameworks without a strong justification. * **Why:** JUnit 5 is the latest version of JUnit and provides a rich set of features for writing and running unit tests. Mockito is a popular mocking framework that simplifies the creation of mock objects. ### 2.2. Structure of Unit Tests * **Do This:** Follow the AAA (Arrange, Act, Assert) pattern in unit tests. * **Arrange:** Set up the environment for the test (e.g., create objects, configure mocks). * **Act:** Execute the code being tested. * **Assert:** Verify that the code behaves as expected. * **Don't Do This:** Mix the Arrange, Act, and Assert sections or perform setup within the assertion. * **Why:** The AAA pattern makes tests more readable and easier to understand. """java import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; import static org.mockito.Mockito.*; class ExampleServiceTest { @Test void testCalculateSum() { // Arrange Calculator calculator = mock(Calculator.class); when(calculator.add(2, 3)).thenReturn(5); ExampleService service = new ExampleService(calculator); // Act int result = service.calculateSum(2, 3); // Assert assertEquals(5, result, "The sum should be 5"); verify(calculator).add(2, 3); // Verify the method was called } } class ExampleService { private Calculator calculator; public ExampleService(Calculator calculator) { this.calculator = calculator; } public int calculateSum(int a, int b) { return calculator.add(a, b); } } interface Calculator { int add(int a, int b); } """ ### 2.3. Mocking Strategies * **Do This:** Use Mockito annotations ("@Mock", "@InjectMocks") to simplify mock creation and injection. """java import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.junit.jupiter.MockitoExtension; import static org.junit.jupiter.api.Assertions.*; import static org.mockito.Mockito.*; @ExtendWith(MockitoExtension.class) class ExampleServiceTest { @Mock private Calculator calculator; @InjectMocks private ExampleService service; @Test void testCalculateSum() { when(calculator.add(2, 3)).thenReturn(5); int result = service.calculateSum(2, 3); assertEquals(5, result, "The sum should be 5"); verify(calculator).add(2, 3); } } """ * **Don't Do This:** Use manual mock creation and injection, which can be verbose and error-prone. Over-mocking - mock only external dependencies, not the class under test itself. * **Why:** Mockito annotations reduce boilerplate code and make tests more readable. ### 2.4. Parameterized Tests * **Do This:** Use JUnit 5's "@ParameterizedTest" to run the same test with different input values. """java import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.CsvSource; import static org.junit.jupiter.api.Assertions.*; class StringUtilsTest { @ParameterizedTest @CsvSource({ "apple, APPLE", "banana, BANANA", "cherry, CHERRY" }) void testConvertToUpperCase(String input, String expected) { assertEquals(expected, StringUtils.convertToUpperCase(input)); } } class StringUtils { static String convertToUpperCase(String input) { return input.toUpperCase(); } } """ * **Don't Do This:** Write separate tests for each input value, which can lead to code duplication. * **Why:** Parameterized tests reduce code duplication and make it easier to test multiple scenarios. ### 2.5. Gradle Test Task Configuration * **Do This:** Configure the Gradle test task to fail the build if tests fail. Consider setting JVM arguments for the test execution. """gradle test { useJUnitPlatform() testLogging { events "passed", "skipped", "failed" exceptionFormat "full" } jvmArgs "-Xmx256m" // Set maximum heap size } """ * **Don't Do This:** Ignore test failures or skip tests during the build. * **Why:** Failing the build on test failures ensures that broken code is not deployed. Providing test logging helps to understand the tests execution and potential failures. ## 3. Integration Testing with Gradle ### 3.1. Purpose of Integration Tests * **Do This:** Write integration tests to verify the interactions between different modules or components of the system. Focus on testing the "seams" between different parts of the application. * **Don't Do This:** Use integration tests to test individual units of code. That's the job of unit tests. * **Why:** Integration tests ensure that the different parts of the system work together correctly. ### 3.2. Testing External Dependencies * **Do This:** Use test containers (e.g., Docker containers) to provide a consistent and isolated environment for integration tests that depend on external services (e.g., databases, message queues). """gradle dependencies { testImplementation("org.testcontainers:testcontainers:1.19.6") testImplementation("org.testcontainers:junit-jupiter:1.19.6") testImplementation("org.testcontainers:postgresql:1.19.6") } """ * **Don't Do This:** Rely on shared or production environments for integration tests, which can lead to inconsistent results and data corruption. * **Why:** Test containers provide a reliable and reproducible environment for integration tests. """java import org.junit.jupiter.api.Test; import org.testcontainers.containers.PostgreSQLContainer; import org.testcontainers.junit.jupiter.Container; import org.testcontainers.junit.jupiter.Testcontainers; import java.sql.*; import static org.junit.jupiter.api.Assertions.assertTrue; @Testcontainers class DatabaseIntegrationTest { @Container private static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15-alpine") .withDatabaseName("testdb") .withUsername("test") .withPassword("test"); @Test void testDatabaseConnection() throws SQLException { String jdbcUrl = postgres.getJdbcUrl(); String username = postgres.getUsername(); String password = postgres.getPassword(); try (Connection connection = DriverManager.getConnection(jdbcUrl, username, password)) { assertTrue(connection.isValid(5), "Connection should be valid"); } } } """ ### 3.3. Mocking External Services * **Do This:** Use mock servers (e.g., WireMock, MockServer) to simulate the behavior of external services that are not available during integration testing. * **Don't Do This:** Make real calls to external services during integration tests, which can be slow, unreliable, and costly. However, avoid over-mocking. Test the actual interactions when reasonable. ### 3.4. Database Testing * **Do This:** Use a dedicated test database and populate it with test data before running integration tests that interact with a database. * **Don't Do This:** Use the production database or modify shared data during integration tests. * **Why:** Using a dedicated test database prevents data corruption. ### 3.5. Transactional Tests * **Do This:** Wrap integration tests that modify data in a transaction and roll back the transaction after the test completes. * **Don't Do This:** Leave data modifications in the database after running integration tests. * **Why:** Transactional tests ensure that the database remains in a consistent state after running tests. ## 4. End-to-End (E2E) Testing with Gradle ### 4.1. Purpose of E2E Tests * **Do This:** Write E2E tests to verify the complete system workflow from the user's perspective. Focus on testing the most critical user journeys. * **Don't Do This:** Use E2E tests to test individual components or units of code. That's the job of unit and integration tests. * **Why:** E2E tests provide the highest level of confidence that the system works as expected. ### 4.2. Automation Frameworks * **Do This:** Use an automation framework (e.g., Selenium, Playwright, Cypress) to automate E2E tests. * **Don't Do This:** Manually run E2E tests, which can be time-consuming and error-prone. * **Why:** Automation frameworks make E2E tests more efficient and reliable. ### 4.3. Test Environments * **Do This:** Run E2E tests in a dedicated test environment that closely resembles the production environment. * **Don't Do This:** Run E2E tests in development environments, which may not be representative of the production environment. * **Why:** Using a dedicated test environment ensures that E2E tests are run in a realistic environment. ### 4.4. Browser Management * **Do This:** Use a browser management tool (e.g., WebDriverManager) to automatically download and manage browser drivers for E2E tests. * **Don't Do This:** Manually download and configure browser drivers, which can be a tedious and error-prone process. * **Why:** Browser management tools simplify the configuration of E2E tests. ### 4.5. Test Data Management * **Do This:** Use a consistent and reliable strategy for managing test data in E2E tests. This may involve creating test data programmatically or using a test data generation tool. * **Don't Do This:** Rely on hardcoded test data or manual data entry, which can be inconsistent and unreliable. * **Why:** Proper test data management ensures that E2E tests are run with consistent and realistic data. ## 5. Gradle and Continuous Integration ### 5.1. Integrating Tests into CI/CD Pipeline * **Do This:** Configure your CI/CD pipeline to automatically run all tests (unit, integration, and E2E) on every commit. * **Don't Do This:** Skip running tests in the CI/CD pipeline, which can lead to broken code being deployed to production. * **Why:** Integrating tests into the CI/CD pipeline provides continuous feedback on the quality of the code. ### 5.2. Parallel Test Execution * **Do This:** Configure Gradle to run tests in parallel to reduce the overall test execution time. """gradle test { maxParallelForks = (Runtime.runtime.availableProcessors() / 2) ?: 1 // Use half the available processors } """ * **Don't Do This:** Run tests sequentially, which can be slow and inefficient. Ensure your tests are written to support parallel execution (e.g., no shared mutable state). * **Why:** Parallel test execution can significantly reduce the time it takes to run the test suite. ### 5.3. Test Reporting * **Do This:** Configure Gradle to generate detailed test reports (e.g., HTML reports) that show the results of each test. Then, integrate the publication of test reports to common CI systems like Jenkins and Github Actions. """gradle test { useJUnitPlatform() reports { junitXml.required = true html.required = true } } """ * **Don't Do This:** Rely on console output to understand the results of tests, which can be difficult to parse and analyze. * **Why:** Test reports provide a clear and concise overview of the test results, making it easier to identify and fix failing tests. ### 5.4. Flaky Test Management * **Do This:** Implement a strategy for identifying and managing flaky tests (tests that sometimes pass and sometimes fail). This may involve re-running flaky tests multiple times or disabling them temporarily. * **Don't Do This:** Ignore flaky tests, which can undermine confidence in the test suite. * **Why:** Flaky tests can lead to false positives and mask real bugs. ### 5.5 Caching Test Results * **Do This:** Enable Gradle's build cache to reuse test outputs between builds, especially in CI environments. This is achieved by ensuring build tasks are properly configured for caching. * **Don't Do This:** Disable or misconfigure the build cache, leading to unnecessary test re-executions and slower build times. ## 6. Common Anti-Patterns * **Ignoring Test Failures:** Never ignore test failures or skip tests; always investigate and fix them. * **Writing Untestable Code:** Design code with testability in mind; avoid tight coupling and hidden dependencies. * **Over-Mocking:** Use mocks judiciously; avoid mocking everything, as it can make tests brittle and less valuable. Test actual interactions when possible. * **Not Cleaning Up After Tests:** Ensure that tests clean up any data or state they create, to avoid interference with other tests. * **Long Setup:** Keep setup as minimal as possible, using helper functions to instantiate objects and mocks. Aim for speed and readability. * **Complex Assertions:** Structure assertions for readability, using Hamcrest matchers or similar libraries to write simple-to-understand validations. ## 7. Security Considerations * **Avoid Storing Secrets in Tests:** Don't hardcode sensitive information (API keys, passwords) in test files. Use environment variables or secure configuration mechanisms. * **Secure Test Environments:** Protect test environments from unauthorized access and ensure data is properly secured and anonymized where needed. * **Regular Security Audits:** Review testing practices and configurations regularly to ensure they align with security best practices. By adhering to these standards, Gradle projects can benefit from improved code quality, reduced bug rates, and enhanced maintainability.
# Security Best Practices Standards for Gradle This document outlines security best practices for Gradle builds. Adhering to these standards helps protect against common vulnerabilities and ensures a more secure build process. These guidelines are specifically tailored for Gradle, incorporating modern approaches and patterns based on the latest Gradle version. ## 1. Dependency Management Security ### 1.1. Using Dependency Version Locking Always use dependency version locking to ensure reproducible and verifiable builds. This prevents unexpected behavior due to transitive dependency updates or malicious package introductions (dependency confusion attacks). Gradle's dependency locking mechanisms are designed for this purpose. * **Do This:** Use Gradle's built-in dependency locking feature. * **Don't Do This:** Rely on dynamic version ranges or "latest.integration" which can introduce unstable or compromised dependencies. **Why:** Locking ensures that the exact same versions are used consistently, mitigating risks associated with supply chain attacks. **Code Example:** """gradle // gradle.build dependencies { implementation 'org.apache.commons:commons-lang3:3.12.0' // ... other dependencies } task lockDependencies { doLast { configurations.all { resolutionStrategy.force(dependencies) } configurations.all { resolutionStrategy.eachDependency { if (requested.group == 'org.apache.commons' && requested.name == 'commons-lang3') { useVersion '3.12.0' // Explicitly set version here if needed. } } } configurations.matching { it.isCanBeResolved }.all { resolutionStrategy.activateDependencyLocking() } } } """ * Execute "./gradlew lockDependencies" to generate "gradle.lockfile". Commit the lockfile to version control. ### 1.2. Regularly Auditing Dependencies for Vulnerabilities Use dependency scanning tools to identify known vulnerabilities in project dependencies. Several plugins and tools integrate with Gradle to provide vulnerability reports. * **Do This:** Integrate a dependency scanning plugin (e.g., OWASP Dependency-Check, Snyk, or Checkmarx). Configure the build to fail if critical vulnerabilities are found. * **Don't Do This:** Ignore vulnerability reports or postpone remediation indefinitely. **Why:** Proactive vulnerability scanning allows for timely remediation, reducing the window of opportunity for attackers. **Code Example (OWASP Dependency-Check plugin):** """gradle plugins { id "org.owasp.dependencycheck" version "9.0.9" } dependencyCheck { analyzers { assembly { enabled = false } } failBuildOnCVSS = 7 // Fail build if CVSS score is above 7 suppressionFile = 'dependency-check-suppression.xml' //Optional file to suppress false positives reportFormat = 'ALL' //Format the report in XML, HTML, and JSON. } """ * Configure a "dependency-check-suppression.xml" to avoid failing due to false positives. ### 1.3. Using Secure Dependency Sources Ensure that dependencies are downloaded from trusted and secured repositories. Central repositories like Maven Central are generally considered safe, but be cautious of custom or internal repositories, since they may not have the same level of security review * **Do This:** Prefer secure repositories served over HTTPS (e.g., Maven Central). * **Don't Do This:** Use insecure repositories that might be susceptible to man-in-the-middle attacks. **Why:** Mitigates the risk of downloading tampered or malicious artifacts. **Code Example:** """gradle repositories { mavenCentral() // Uses HTTPS by default google() // Uses HTTPS by default // Example using a self-hosted maven server which SHOULD use HTTPS maven { url "https://internal.example.com/maven" credentials { username = "user" password = "password" } } } """ ### 1.4. Verifying Dependency Integrity Use checksum verification to ensure that downloaded dependencies haven't been tampered with during transit. * **Do This:** Utilize Gradle's built-in support for checksum verification. * **Don't Do This:** Disable checksum verification unless absolutely necessary due to a trusted offline build environment. **Why:** Checksums ensure that the downloaded artifacts match the expected cryptographic hash, confirming integrity. **Code Example:** Gradle automatically verifies checksums if they are published alongside the artifacts in the repository. No explicit configuration is generally needed. If verification fails, Gradle throws an exception. Consider configuring repository metadata when using repository managers such as Artifactory and Nexus. ## 2. Secure Plugin Management ### 2.1. Only Use Trusted Plugins Evaluate the reputation and security of plugins before incorporating them into your build. Prefer plugins from well-known and trusted sources. * **Do This:** Carefully vet the plugin author, review the plugin's permissions, and check for any known vulnerabilities before applying a given Gradle plugin. * **Don't Do This:** Blindly apply plugins from untrusted sources without understanding their potential impact **Why:** Malicious plugins can compromise the build process. Avoid using plugins whose source code is not publicly available and auditable. **Code Example:** """gradle plugins { id("com.example.my-plugin") version("1.0.0") // Applying a plugin from a trusted source // Avoid: id("com.random-user.unvetted-plugin") version ("latest") -- bad practice. } """ ### 2.2. Plugin Version Management Use specific plugin versions instead of dynamic version ranges to avoid unexpected changes in plugin behavior or the introduction of vulnerabilities. * **Do This:** Specify exact versions for all plugins used in the build script. * **Don't Do This:** Rely on dynamic "+" or "latest.release" version specifiers. **Why:** Pinning plugin versions ensures a predictable and reproducible build process. **Code Example:** """gradle plugins { id 'java' version '17' // Correct: Specific version // id 'java' version '+' // Incorrect: Dynamic version } """ ### 2.3. Limiting Plugin Permissions Minimize the permissions granted to plugins. If a plugin requires broad access, carefully evaluate the necessity. * **Do This:** Understand a plugin's required permissions before applying it. Only use plugins that require the minimum permissions to function. * **Don't Do This:** Grant unnecessary permissions to plugins without a clear understanding of the potential risks. **Why:** Restricting permissions limits the potential damage from a compromised plugin. **Example:** (Configuration varies by plugin; examine plugin documentation.) ## 3. Secrets Management ### 3.1. Avoid Hardcoding Secrets Never hardcode sensitive information (API keys, passwords, etc.) directly in the Gradle build files or source code. * **Do This:** Store secrets in environment variables, secure configuration files, or dedicated secrets management tools. * **Don't Do This:** Commit secrets to version control. **Why:** Hardcoded secrets are easily exposed, leading to security breaches. **Code Example (using environment variables):** """gradle def apiKey = System.getenv("API_KEY") ?: "default_api_key" //Provide a default for local development. tasks.register('myTask') { doLast { println "API key: ${apiKey}" } } """ ### 3.2. Using Secure Properties Files Encrypt your Gradle properties files, especially if they contain sensitive information. You can use tools like "gpg" or other encryption utilities. * **Do This:** Encrypt sensitive properties files using "gpg" (or similar tools), and store the decryption key securely. * **Don't Do This:** Store unencrypted credentials in "gradle.properties" or similar files. **Why:** Encryption protects secrets from unauthorized access, even if the file is compromised. **Workflow Example:** 1. Encrypt "gradle.properties" using GPG: "gpg -c gradle.properties" 2. Add ".gradle.properties.gpg" to version control (but NOT "gradle.properties"). 3. In your Gradle build script, decrypt the file before accessing the properties: """gradle import org.gradle.api.Project import org.gradle.api.Task ext.getDecryptedProperties = { Project project, String encryptedFile, String outputFile -> def encryptedFilePath = project.file(encryptedFile).absolutePath def outputFilePath = project.file(outputFile).absolutePath def gpgCmd = ["gpg", "--batch", "--passphrase", System.getenv("GPG_PASSPHRASE"), "--output", outputFilePath, "--decrypt", encryptedFilePath] //Ensure GPG_PASSPHRASE is set! def process = new ProcessBuilder(gpgCmd).start() process.waitFor() if (process.exitValue() != 0) { throw new GradleException("Failed to decrypt ${encryptedFile}. Ensure GPG_PASSPHRASE is set environment.") } def properties = new Properties() project.file(outputFile).withInputStream { stream -> properties.load(stream) } return properties } tasks.register('loadSecrets') { doFirst { def secrets = getDecryptedProperties(project, ".gradle.properties.gpg", "gradle.properties") //decrypt to gradle.properties secrets.each { name, value -> project.ext.set(name, value) // Make all properties extensible properties in Gradle } } } //Define 'loadSecrets' task as a dependency to tasks that require secrets, such as: tasks.register('myTask') { dependsOn 'loadSecrets' doLast { println "My Secret: ${project.MY_SECRET_KEY}" // access as extensible property } } """ * Important: The GPG_PASSPHRASE environment variable *must never* be stored in version control, or hardcoded. It should be provided by the CI/CD environment, or the user system. ### 3.3. Using Third-Party Secrets Managers Consider using dedicated secrets management solutions like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault for storing and managing secrets securely. * **Do This:** Use a secrets management solution. * **Don't Do This:** Roll your own homegrown secrets management or rely on less secure storage mechanisms. **Why:** Secrets managers offer features like encryption, access control, auditing, and rotation, providing a more robust security posture. **Code Example (using AWS Secrets Manager):** This example uses AWS Secrets Manager; however, using any secrets manager would provide a higher degree of security than storing secrets within the project itself or in environment variables. """gradle plugins { id 'java' } repositories { mavenCentral() } dependencies { implementation 'com.amazonaws:aws-java-sdk-secretsmanager:1.12.619' } tasks.register('getSecretFromAWS') { doLast { def secretName = "my-secret"; def region = "us-east-1"; try { // Create a Secrets Manager client com.amazonaws.services.secretsmanager.AWSSecretsManager client = com.amazonaws.services.secretsmanager.AWSSecretsManagerClientBuilder.standard() .withRegion(region) .build(); // Retrieve the secret com.amazonaws.services.secretsmanager.model.GetSecretValueRequest getSecretValueRequest = new com.amazonaws.services.secretsmanager.model.GetSecretValueRequest() .withSecretId(secretName); com.amazonaws.services.secretsmanager.model.GetSecretValueResult getSecretValueResult = client.getSecretValue(getSecretValueRequest); // Parse the secret (assuming it's a JSON string) def secretString = getSecretValueResult.getSecretString(); def secretJson = new groovy.json.JsonSlurper().parseText(secretString); // Access individual secrets def username = secretJson.username; def password = secretJson.password; println "Username: " + username; println "Password: " + password; } catch (Exception e) { println "Error retrieving secret: " + e.getMessage(); } } } """ **Note:** Configure AWS credentials (e.g., via IAM roles or access keys in AWS config) for the code to access Secrets Manager. Ensure these credentials have the *minimum required permissions* and are handled following best practices for credential management. ## 4. Build Process Security ### 4.1. Limiting Build Script Access Restrict write access to build scripts ("build.gradle", "settings.gradle", etc.) and related files. Prevent unauthorized modifications that could inject malicious code. * **Do This:** Implement strict access control policies for build files. * **Don't Do This:** Grant broad write access to build scripts to untrusted users or processes. **Why:** Prevents attackers from tampering with the build logic. ### 4.2. Input Validation Validate all inputs to Gradle tasks, especially those coming from external sources (e.g., command-line arguments, environment variables, network requests). * **Do This:** Sanitize and validate inputs before using them in tasks. * **Don't Do This:** Trust inputs implicitly without proper validation. **Why:** Protects against injection attacks and other input-related vulnerabilities. **Code Example:** """gradle tasks.register('processInput') { inputs.property("userInput", project.hasProperty('userInput') ? project.property('userInput') : "") //Optional fallback doLast { def userInput = inputs.properties["userInput"] if (userInput != null && !userInput.isEmpty()) { if (isValidInput(userInput)) { // Custom function to validate input println "Processing valid input: ${userInput}" // Further processing here } else { throw new GradleException("Invalid input provided: ${userInput}") } } else { println "No user input provided." } } } boolean isValidInput(String input) { // Implement validation logic here (e.g., regex checks, length limits) return input.matches("^[a-zA-Z0-9]*$") //Only permit alphanumeric inputs } """ ### 4.3. Build Environment Hardening Harden the build environment to minimize the attack surface. Remove unnecessary tools and services. * **Do This:** Run builds in a containerized environment. * **Don't Do This:** Use build servers with excessive software installed or unnecessary network connectivity. **Why:** Reduces the risk of exploitation due to vulnerabilities in the build environment. ### 4.4. Using Safe Code Generation When using code generation tools in your build, ensure these tools and their templates are secure. Validate generated code to prevent introduction of vulnerabilities. * **Do This:** Carefully review code generation tools and ensure their templates cannot be manipulated. * **Don't Do This:** Blindly trust generated code. ### 4.5. Avoiding Deprecated Features Avoid using deprecated features in Gradle that have known security issues. Migrate to recommended alternatives. * **Do This:** Refer to Gradle's release notes and documentation for information about deprecated features, and migrate away from them. * **Don't Do This:** Continue to use deprecated functionality without understanding the risks. **Why:** Deprecated features may no longer receive security updates. ## 5. Output Security ### 5.1. Secure Distribution of Build Artifacts Ensure that build artifacts (JARs, WARs, etc.) are distributed securely. Use secure protocols (HTTPS) for transferring artifacts. * **Do This:** Distribute artifacts through secure channels like HTTPS. * **Don't Do This:** Use insecure protocols or public repositories without appropriate access controls. **Why:** Protects against tampering during distribution. ### 5.2. Sign Artifacts Sign build artifacts with a digital signature to verify their authenticity and integrity. Use tools like "jarsigner". * **Do This:** Sign artifacts with a trusted key using jarsigner. * **Don't Do This:** Distribute unsigned artifacts. **Why:** Digital signatures provide assurance that the artifact hasn't been tampered with and comes from a trusted source. **Workflow Example:** """gradle signing { sign configurations.archives } task signArchives { dependsOn assemble doLast { def keystoreLocation = System.getenv("SIGNING_KEYSTORE_LOCATION") def keystorePass = System.getenv("SIGNING_KEYSTORE_PASSWORD") def keyAlias = System.getenv("SIGNING_KEY_ALIAS") def keyPass = System.getenv("SIGNING_KEY_PASSWORD") if (!keystoreLocation || !keystorePass || !keyAlias || !keyPass) { throw new GradleException("Signing variables not set. Check SIGNING_KEYSTORE_LOCATION, SIGNING_KEYSTORE_PASSWORD, SIGNING_KEY_ALIAS, SIGNING_KEY_PASSWORD environment variables.") } File keystoreFile = file(keystoreLocation) if(!keystoreFile.exists()) { throw new GradleException("Keystore file not found at ${keystoreLocation}") } ant.taskdef(name: 'signjar', classname: 'net.sf.antcontrib.contrib.SignJar', classpath: configurations.compileClasspath.asPath) configurations.archives.artifacts.each { artifact -> def jarFile = artifact.file println "Signing: ${jarFile.name}" ant.signjar( jar: jarFile.absolutePath, alias: keyAlias, keystore: keystoreFile.absolutePath, storepass: keystorePass, keypass: keyPass ) } } } uploadArchives { dependsOn signArchives repositories { maven { url "https://internal.example.com/maven" //MUST use https! credentials { username = "user" password = "password" } } } } """ * Ensure you have the "ant-contrib" library on your classpath ("buildscript" configuration). Refer to the "ant-contrib" documentation for the latest version. * **Securely** manage and protect the signing key and associated passwords. Do not expose them in the build script or commit them to version control. These environment variables should be managed by the CI/CD environment. ### 5.3. Scan Output Artifacts for Vulnerabilities Scan the final build artifacts for vulnerabilities before distributing them. This is the last line of defense against potential security issues. * **Do This:** Integrate vulnerability scanning into the build process. * **Don't Do This:** Distribute artifacts without scanning them for vulnerabilities. ### 5.4 Remove Unnecessary Debug Information Remove unnecessary debug information from the final build artifacts to reducing the amount of information available to attackers. This can be as simple as setting a compiler flag or by using a build profile. * **Do This:** Strip debugging information from release builds * **Don't Do This:** Include debug information in production builds. **Code Example:** """gradle tasks.withType(JavaCompile) { options.compilerArgs.add('-parameters')// enable parameter names in the .class files if (!project.hasProperty('dev')) { //disable in dev builds options.compilerArgs.add('-g:none') // Remove debugging info for non-dev builds. } } """ ## 6. Continuous Integration/Continuous Delivery (CI/CD) Specific Guidance ### 6.1 Secure CI/CD Pipelines Ensure that CI/CD pipelines themselves are isolated and secured. Vulnerabilities in the CI/CD pipeline itself can be exploited to compromise builds. * **Do This:** Follow security best practices for your CI/CD system (e.g., least privileged access controls, frequent audits, patched systems) * **Don't Do This:** Use shared credentials unnecessarily, ignore warnings from the CI/CD system, or skip patching. ### 6.2 Verification Steps In CI/CD Integrate security checks into the CI/CD pipeline to enforce security policies and catch security issues early. * **Do This:** Add automated security scans into the CI/CD pipeline to scan for vulnerabilities with tools like OWASP Dependency-Check. * **Don't Do This:** Assume that because code compiles that it is secure. ### 6.3 Immutable Build Environments Where possible, make the build environment immutable. Prevent modifications to the build environment during builds. * **Do This:** Build images for CI/CD pipelines, rather than modifying them directly. * **Don't Do This:** Modify the build environment during the build. ## 7. Logging and Auditing ### 7.1. Log Important Build Events Use Gradle's logging system to record important build events, such as dependency resolutions, plugin applications, and task executions. This enables you to audit build processes and identify potential security threats. * **Do This:** Use Gradle's logging system to log security-relevant events. Configure external logging where possible for audit logs. * **Don't Do This:** Log secrets. **Why:** Logs provide a record of build activities, aiding in security investigations and compliance. **Code Example:** """gradle tasks.register('someTask') { doLast { logger.warn "This is a task that logs." } } """ By implementing these security best practices, you can significantly improve the security posture of your Gradle builds. Regularly review and update these standards to address emerging threats and vulnerabilities.
# Core Architecture Standards for Gradle This document outlines the core architecture standards for Gradle projects, designed to promote maintainability, performance, and security. It serves as a guide for developers and provides context for AI coding assistants. These standards reflect modern best practices and leverage the latest Gradle features. ## 1. Project Structure and Organization A well-defined project structure promotes discoverability, reduces complexity, and simplifies maintenance. ### 1.1 Multi-Project Builds For non-trivial projects, adopt a multi-project build structure. This modular approach improves build times, encourages code reuse, and isolates concerns. * **Do This:** Organize your code into logical modules based on functionality or domain. * **Don't Do This:** Lump all code into a single, monolithic project. * **Why This Matters:** Improves build performance (parallel execution), enhances code reusability, and simplifies refactoring. """gradle // settings.gradle.kts rootProject.name = "my-application" include("core") include("api") include("service") include("client") """ """gradle // core/build.gradle.kts plugins { java } dependencies { implementation("org.apache.commons:commons-lang3:3.12.0") } """ * **Anti-Pattern:** A single large "build.gradle.kts" file containing all dependencies and configurations. ### 1.2 Standard Directory Layout Follow the standard Gradle directory layout for each project. * **Do This:** Use "src/main/java" for production Java code, "src/test/java" for test code, "src/main/resources" for resources, and "src/test/resources" for test resources. * **Don't Do This:** Deviate from the standard layout without a compelling reason. Custom source sets should be used sparingly and documented clearly. * **Why This Matters:** Enables Gradle to automatically recognize and process source files, reducing configuration overhead. * **Example:** """ my-application/ ├── settings.gradle.kts ├── core/ │ ├── build.gradle.kts │ └── src/ │ ├── main/ │ │ └── java/ │ │ └── com/example/core/ │ │ └── CoreClass.java │ └── test/ │ └── java/ │ └── com/example/core/ │ └── CoreClassTest.java ├── api/ │ └── ... └── service/ └── ... """ ### 1.3 Convention over Configuration Embrace Gradle's convention-over-configuration approach. Leverage sensible defaults provided by plugins. * **Do This:** Use plugins and let them handle common tasks such as compilation and testing. * **Don't Do This:** Manually configure tasks that are already handled by plugins, unless customization is absolutely necessary. * **Why This Matters:** Reduces build script complexity and makes the build more maintainable. """gradle // build.gradle.kts plugins { java } repositories { mavenCentral() } dependencies { implementation("org.springframework:spring-core:6.1.0") testImplementation("org.junit.jupiter:junit-jupiter-api:5.11.0-M1") testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.11.0-M1") } tasks.test { useJUnitPlatform() } """ ## 2. Modularization and Abstraction Proper modularization and abstraction are critical for large projects. Aim for loosely coupled, highly cohesive modules. ### 2.1 Domain-Driven Design (DDD) Consider applying DDD principles to structure your modules around domain concepts. * **Do This:** Create modules that represent bounded contexts or aggregates from your domain. * **Don't Do This:** Create modules that are purely technical or infrastructural. * **Why This Matters:** Improves code understandability, promotes easier changes, and aligns the codebase with the business domain. DDD practices should be well-documented for clarity. ### 2.2 Interface-Based Design Prefer interface-based design to decouple modules. * **Do This:** Define interfaces in one module and implement them in another. * **Don't Do This:** Directly depend on concrete classes in other modules. * **Why This Matters:** Reduces dependencies and increases flexibility. """java // api/src/main/java/com/example/api/GreetingService.java package com.example.api; public interface GreetingService { String greet(String name); } """ """java // service/src/main/java/com/example/service/GreetingServiceImpl.java package com.example.service; import com.example.api.GreetingService; public class GreetingServiceImpl implements GreetingService { @Override public String greet(String name) { return "Hello, " + name + "!"; } } """ """gradle // service/build.gradle.kts dependencies { implementation(project(":api")) } """ ### 2.3 Dependency Injection (DI) Use DI to manage dependencies between modules. frameworks like Spring or Guice can be used if complexity warrants. Otherwise, constructor injection works well with modern Kotlin. * **Do This:** Inject dependencies into classes instead of creating them directly. * **Don't Do This:** Use service locators or singleton patterns excessively for dependency management. * **Why This Matters:** Reduces coupling, improves testability, and simplifies configuration. """java // service/src/main/java/com/example/service/MyService.java package com.example.service; import com.example.api.GreetingService; public class MyService { private final GreetingService greetingService; public MyService(GreetingService greetingService) { this.greetingService = greetingService; } public String doSomething(String name) { return greetingService.greet(name); } } """ ## 3. Build Script Design Clean and well-structured build scripts are crucial for maintainability. ### 3.1 Kotlin DSL Use the Kotlin DSL for Gradle build scripts. This offers superior type safety, IDE support, and readability compared to Groovy. * **Do This:** Write all new build scripts using Kotlin DSL ("*.gradle.kts"). * **Don't Do This:** Use Groovy DSL ("*.gradle") for new projects. Migrate existing Groovy builds when feasible. * **Why This Matters:** Improves maintainability, reduces errors, and provides better IDE integration (autocompletion, refactoring). """kotlin // build.gradle.kts plugins { kotlin("jvm") version "1.9.21" } group = "com.example" version = "1.0-SNAPSHOT" repositories { mavenCentral() } dependencies { implementation(kotlin("stdlib")) testImplementation("org.junit.jupiter:junit-jupiter-api:5.11.0-M1") testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.11.0-M1") } tasks.test { useJUnitPlatform() } """ ### 3.2 Build Logic Extraction Extract common build logic into reusable functions or plugins. * **Do This:** Identify repetitive tasks or configurations and move them into separate files ("buildSrc" directory, custom plugins, or script plugins). * **Don't Do This:** Duplicate build logic across multiple projects. * **Why This Matters:** Reduces redundancy, simplifies maintenance, and ensures consistency. """kotlin // buildSrc/src/main/kotlin/my-conventions.gradle.kts plugins { id("java") } dependencies { implementation("org.apache.commons:commons-lang3:3.12.0") } tasks.test { useJUnitPlatform() } """ """gradle // build.gradle.kts plugins { id("my-conventions") } dependencies { implementation("org.springframework:spring-core:6.1.0") // extra dependency } """ ### 3.3 Version Catalogues Use version catalogues to manage dependencies and plugins versions centrally. This ensures consistency across the build. * **Do This:** Define all dependency and plugin versions in the "gradle/libs.versions.toml" file. * **Don't Do This:** Hardcode versions directly in the "build.gradle.kts" files. * **Why This Matters:** Simplifies dependency management, ensures consistency, and reduces the risk of conflicts. """toml # gradle/libs.versions.toml [versions] springBoot = "3.2.0" kotlin = "1.9.21" junit = "5.11.0-M1" [libraries] spring-web = { module = "org.springframework.boot:spring-web", version.ref = "springBoot" } kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" } junit-jupiter-api = { module = "org.junit.jupiter:junit-jupiter-api", version.ref = "junit" } junit-jupiter-engine = { module = "org.junit.jupiter:junit-jupiter-engine", version.ref = "junit" } [plugins] kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" } spring-boot = { id = "org.springframework.boot", version.ref = "springBoot" } spring-dependency-management = { id = "io.spring.dependency-management", version = "1.1.4" } """ """gradle // build.gradle.kts plugins { alias(libs.plugins.kotlin.jvm) alias(libs.plugins.spring.boot) alias(libs.plugins.spring.dependency.management) } dependencies { implementation(libs.spring.web) implementation(libs.kotlin.stdlib) testImplementation(libs.junit.jupiter.api) testRuntimeOnly(libs.junit.jupiter.engine) } """ ### 3.4 Task Configuration Avoidance Use configuration avoidance APIs when configuring tasks, especially for large projects. These APIs delay task configuration until absolutely necessary, decreasing configuration time. * **Do This:** Use "tasks.register" instead of "tasks.create" or direct property assignment where possible. Use "named" instead of direct access to task properties when configuring. * **Don't Do This:** Eagerly configure tasks that might not be executed. * **Why This Matters:** Decreases build configuration time, especially in large multi-project builds. """kotlin // build.gradle.kts tasks.register<Copy>("copyDocs") { from("src/docs") into("build/docs") } tasks.named<Test>("test") { useJUnitPlatform() } """ ### 3.5 Incremental Builds Leverage Gradle's incremental build capabilities to avoid unnecessary work. * **Do This:** Ensure that your tasks are properly configured for incremental builds (e.g., declare inputs and outputs). Use "@Input", "@OutputDirectory", "@InputFile", "@InputChanges", etc., annotations. * **Don't Do This:** Write tasks that always execute from scratch, even when inputs haven't changed. The "@TaskAction" method should be as lean as possible. * **Why This Matters:** Significantly reduces build times by only re-executing tasks when necessary. """java // src/main/java/com/example/customtask/GenerateFileTask.java package com.example.customtask; import org.gradle.api.DefaultTask; import org.gradle.api.file.DirectoryProperty; import org.gradle.api.file.RegularFileProperty; import org.gradle.api.provider.Property; import org.gradle.api.tasks.*; import java.io.File; import java.io.FileWriter; import java.io.IOException; public abstract class GenerateFileTask extends DefaultTask { @Input public abstract Property<String> getMessage(); @OutputDirectory public abstract DirectoryProperty getOutputDir(); @TaskAction public void generate() throws IOException { File outputDir = getOutputDir().get().getAsFile(); if (!outputDir.exists()) { outputDir.mkdirs(); } File outputFile = new File(outputDir, "message.txt"); try (FileWriter writer = new FileWriter(outputFile)) { writer.write(getMessage().get()); } } } """ """kotlin // build.gradle.kts tasks.register<com.example.customtask.GenerateFileTask>("generateMessage") { message.set("Hello, Gradle!") outputDir.set(file("build/generated")) } """ ## 4. Dependency Management Efficient dependency management is crucial for build stability and performance. ### 4.1 Consistent Dependency Versions Enforce consistent versions for all dependencies. Transitive dependency management can lead to version conflicts. Use dependency constraints or BOMs (Bill of Materials) to manage dependency versions centrally. Version catalogues are also useful in this regard. * **Do This:** Define dependency versions consistently across all modules. Use "dependencyConstraints" or BOMs to enforce version consistency. Version catalogues (as described above) are an excellent option. * **Don't Do This:** Allow inconsistent dependency versions across the project. * **Why This Matters:** Prevents runtime errors and ensures that all modules use compatible versions of dependencies. Resolves dependency conflicts. """gradle // build.gradle.kts dependencies { implementation("org.springframework:spring-core:6.1.0") implementation("org.springframework:spring-context:6.1.0") } dependencyConstraints { implementation("org.springframework:spring-core:6.1.0") { because("Ensures consistent Spring Core version") } } """ ### 4.2 Dynamic Versions Avoidance Avoid using dynamic versions (e.g., "1.0.+", "latest.release") for dependencies. * **Do This:** Specify explicit, fixed versions for all dependencies. * **Don't Do This:** Use dynamic versions, as they can lead to unpredictable builds. * **Why This Matters:** Ensures that the build is reproducible and that dependencies are consistent across builds. Prevents unexpected behavior due to dependency updates. ### 4.3 Repository Management Configure repositories correctly and securely. * **Do This:** Declare only the necessary repositories. Use HTTPS for all repositories. Consider using a repository manager (e.g., Nexus, Artifactory) for better control and caching. * **Don't Do This:** Use insecure HTTP repositories. Declare unnecessary repositories. * **Why This Matters:** Improves build security and performance. Reduces the risk of downloading malicious or compromised dependencies. """gradle // settings.gradle.kts dependencyResolutionManagement { repositories { mavenCentral() gradlePluginPortal() } } """ ### 4.4 Resolution Strategies Leverage Gradle's dependency resolution strategies to handle conflicts and customize dependency resolution. * **Do This:** Use "force" to enforce specific versions, "failOnVersionConflict" to detect conflicts, and "eachDependency" to customize dependency resolution. * **Don't Do This:** Ignore dependency conflicts or allow Gradle to resolve them automatically without understanding the implications. * **Why This Matters:** Provides fine-grained control over dependency resolution and helps prevent runtime errors. """gradle // build.gradle.kts configurations.all { resolutionStrategy { force("org.apache.commons:commons-lang3:3.12.0") failOnVersionConflict() } } """ ## 5. Security Considerations Security should be a primary concern throughout the build process. ### 5.1 Dependency Vulnerability Scanning Integrate dependency vulnerability scanning into your build process. * **Do This:** Use plugins like "org.owasp.dependencycheck" to scan dependencies for known vulnerabilities. * **Don't Do This:** Ignore dependency vulnerabilities or fail to address them promptly. * **Why This Matters:** Helps identify and mitigate security risks associated with vulnerable dependencies. """gradle // build.gradle.kts plugins { id("org.owasp.dependencycheck") version "9.0.9" } dependencyCheck { suppressionFile = "suppressions.xml" } """ ### 5.2 Secure Repository Credentials Protect repository credentials. * **Do This:** Store repository credentials securely (e.g., using environment variables or Gradle properties) and avoid committing them to version control. * **Don't Do This:** Hardcode repository credentials in build scripts or store them in version control. Use masked properties where appropriate. * **Why This Matters:** Prevents unauthorized access to your repositories. """gradle // gradle.properties nexusUsername=myuser nexusPassword=mypassword """ """gradle //build.gradle.kts repositories { maven { url = uri("https://nexus.example.com/repository/maven-releases/") credentials { username = project.properties["nexusUsername"] as String? ?: System.getenv("NEXUS_USERNAME") password = project.properties["nexusPassword"] as String? ?: System.getenv("NEXUS_PASSWORD") } } } """ ### 5.3 Build Script Security Secure your build scripts. * **Do This:** Review build scripts regularly for security vulnerabilities (e.g., command injection, arbitrary code execution). Use static analysis tools to detect potential security issues. Avoid using untrusted third-party plugins. * **Don't Do This:** Execute untrusted build scripts without careful review. * **Why This Matters:** Prevents malicious actors from compromising your build process. ## 6. Testing Practices Comprehensive testing is essential for software quality. ### 6.1 Unit Testing Write comprehensive unit tests for all modules. * **Do This:** Use a testing framework (e.g., JUnit, TestNG, Kotest) and aim for high code coverage. Follow the Arrange-Act-Assert pattern. * **Don't Do This:** Skip unit tests or write tests that are superficial or incomplete. * **Why This Matters:** Catches bugs early, provides confidence in code changes, and facilitates refactoring. """java // src/test/java/com/example/service/GreetingServiceImplTest.java package com.example.service; import com.example.api.GreetingService; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class GreetingServiceImplTest { @Test void greet() { GreetingService greetingService = new GreetingServiceImpl(); String greeting = greetingService.greet("World"); assertEquals("Hello, World!", greeting); } } """ ### 6.2 Integration Testing Write integration tests to verify interactions between modules. * **Do This:** Test the integration of different modules or components. Use testcontainers or similar tools to simulate external dependencies (databases, message queues). * **Don't Do This:** Neglect integration testing, as it can uncover issues that are not apparent in unit tests. * **Why This Matters:** Verifies that different parts of the system work together correctly. ### 6.3 Test Task Configuration Configure the test task appropriately. * **Do This:** Configure JVM arguments, test logging, and other test parameters as needed. Use Gradle's test reporting features to generate test reports. * **Don't Do This:** Use default test task configurations without considering the specific requirements of your project. * **Why This Matters:** Ensures that tests are executed correctly and that test results are easily accessible. """kotlin // build.gradle.kts tasks.test { useJUnitPlatform() jvmArgs("-Xmx256m") testLogging { events("passed", "skipped", "failed") } } """ ## 7. Documentation Good documentation is crucial for long-term maintainability. ### 7.1 Code Documentation Document your code clearly and concisely. * **Do This:** Use Javadoc or KotlinDoc to document classes, methods, and fields. Explain the purpose, usage, and limitations of each element. * **Don't Do This:** Neglect code documentation, as it makes the code harder to understand and maintain. * **Why This Matters:** Improves code understandability, facilitates collaboration, and simplifies maintenance. ### 7.2 Build Script Documentation Document your build scripts. * **Do This:** Explain the purpose of each task, dependency, and configuration setting. Use comments to clarify complex logic. Include a README file with instructions on how to build and run the project. * **Don't Do This:** Write build scripts without any documentation, as it makes them harder to understand and maintain. Use meaningful commit messages documenting changes to the build. * **Why This Matters:** Simplifies build maintenance and ensures that others can understand and modify the build process. ### 7.3 Architecture Documentation Document the overall architecture of your project. * **Do This:** Create diagrams and documents that describe the modules, their dependencies, and the interactions between them. Explain the key design decisions and trade-offs. * **Don't Do This:** Fail to document the architecture, as it makes it harder to understand the big picture and make informed decisions. * **Why This Matters:** Provides a high-level overview of the project and helps ensure that all developers are on the same page. This comprehensive guide covers the core architecture standards for Gradle projects, emphasizing maintainability, performance, and security, using the latest Gradle features and modern best practices. It provides guidance for developers and serves as context for AI coding assistants.