All 15 Build Tools: Maven & Gradle questions
More in Build Tools: Maven & Gradle
How does Gradle's build script (build.gradle / build.gradle.kts) differ structurally from Maven's declarative XML pom.xml? What is the difference between Maven's <dependencies> scope values (compile, provided, runtime, test) and how do they affect what's included in the final packaged artifact? How do you resolve a dependency version conflict manually in Maven using exclusions, and when would this be necessary despite the automatic nearest-wins resolution? What is a Maven BOM (Bill of Materials), and how does it help manage consistent dependency versions across a multi-module project or organization? How do you configure the Maven Compiler Plugin to target a specific Java language version, and what's the difference between source, target, and release configuration? How does Maven's dependency resolution algorithm handle transitive dependency version conflicts, and what is the "nearest definition wins" rule? How does Gradle's incremental build and build cache mechanism achieve significantly faster rebuild times compared to Maven's default behavior? How would you configure a multi-module Maven or Gradle project, and what benefits does modularizing a large codebase this way provide? How would you write a custom Maven plugin or Gradle task to perform project-specific build automation not covered by existing plugins? How would you configure a Maven or Gradle build to produce a reproducible build (bit-for-bit identical output given the same source), and why does this matter for supply chain security?
Advertisement
Java › Build Tools: Maven & Gradle

How do you manage different configurations for different environments (development, staging, production) using Maven profiles or Gradle's equivalent mechanisms?

Intermediate

Answer

Maven profiles (<profiles> in pom.xml, activated via -P flag, an environment variable, or automatic activation conditions) let you conditionally include different dependencies, properties, or plugin configurations depending on which profile is active -- Gradle typically achieves the same outcome more flexibly through plain conditional logic in the build script itself (checking a project property or environment variable), or through separate source sets/build variants, since Gradle's scripting nature doesn't require a dedicated "profile" abstraction the way Maven's declarative model does.
<!-- Maven profile for production-specific configuration -->
<profiles>
    <profile>
        <id>production</id>
        <properties>
            <log.level>WARN</log.level>
        </properties>
    </profile>
</profiles>

# Activate explicitly
mvn package -Pproduction
Real-world example A CI/CD pipeline activates a different Maven profile depending on the deployment target (dev, staging, production), each profile substituting the appropriate database connection properties and logging configuration into the packaged artifact without maintaining entirely separate pom.xml files per environment.

Common follow-ups: What are the risks of baking environment-specific configuration directly into the build artifact versus externalizing it at deploy/runtime instead?;How does Gradle's build variant / source set approach compare structurally to Maven profiles?

Configuration & Options Pattern;Deploy Checklist
All 15 Build Tools: Maven & Gradle questions