Introduction

Gradle does not have a single feature that maps one-to-one to Maven profiles. Instead, Gradle usually solves the same problem with project properties, conditional configuration, source sets, product flavors, or separate tasks depending on the kind of build variation you need.

So the practical answer is not "what is the exact Gradle profile feature." The practical answer is "what are you trying to vary, and which Gradle mechanism matches that variation best."

What Maven Profiles Usually Do

In Maven, profiles are a bundle of conditional build settings. They are commonly used to switch:

• environment-specific properties
• dependencies
• plugins
• resource filtering
• packaging behavior

You might activate a profile with -Pprod or -Pdev and let the pom.xml change accordingly.

Gradle can do the same kinds of things, but it usually does them more explicitly.

The Closest Common Pattern in Gradle: Project Properties

For many builds, the simplest replacement is a project property read from -P.

1def env = project.findProperty("env") ?: "dev"
2
3println "Building for environment: ${env}"
4
5dependencies {
6    if (env == "prod") {
7        implementation "com.example:real-client:1.0.0"
8    } else {
9        implementation "com.example:stub-client:1.0.0"
10    }
11}
12
13tasks.register("printEnv") {
14    doLast {
15        println "Selected environment: ${env}"
16    }
17}

Run it like this:

./gradlew build -Penv=prod

This covers a large portion of what people used Maven profiles for.

Other Gradle Features That Replace Profiles

The right Gradle feature depends on the problem.

Use:

• project properties for simple switches such as dev versus prod
• source sets when code or resources differ by build type
• custom tasks when behavior changes at execution time
• Android build types or product flavors when working in the Android ecosystem

For example, if the difference is not just a property but a different resource directory, source sets are often clearer than packing everything into one big conditional block.

Keep the Build Logic Explicit

One reason Gradle does not need a direct Maven-profile clone is that the build script is already a programmable DSL. You can express conditional logic directly.

That flexibility is powerful, but it can also be abused. If you recreate dozens of Maven-style profiles with nested if statements, the Gradle build quickly becomes hard to understand.

A better pattern is to ask:

• is this really a property
• is this really a separate task
• is this really a separate source set
• is this really a CI concern rather than a build-script concern

That keeps the build maintainable.

Example: Environment-Specific Resource Value

Here is a small example that writes a property into generated resources based on -Penv:

1def env = project.findProperty("env") ?: "dev"
2
3tasks.register("writeConfig") {
4    def outputFile = layout.buildDirectory.file("generated/config/app.properties")
5
6    outputs.file(outputFile)
7
8    doLast {
9        def file = outputFile.get().asFile
10        file.parentFile.mkdirs()
11        file.text = "app.environment=${env}\n"
12    }
13}
14
15processResources.dependsOn(tasks.named("writeConfig"))

This is more explicit than a hidden profile. You can see exactly where the variation enters the build.

Common Pitfalls

• Searching for a direct Maven-profile clone instead of modeling the actual Gradle use case.
• Putting too much imperative branching into build.gradle and making the build hard to reason about.
• Using environment variables and project properties inconsistently across local development and CI.
• For Android, ignoring build types and flavors, which are often the natural answer.
• Treating every environment difference as a build-script problem when some differences belong in deployment configuration instead.

Summary

• Gradle has no exact equivalent to Maven profiles.
• Project properties with -P are the closest replacement for many use cases.
• Source sets, custom tasks, and Android flavors often model the variation more cleanly.
• The best Gradle answer depends on what you are trying to vary.
• Think in terms of explicit build logic, not feature-by-feature Maven translation.