Maven Profiles vs Spring Profiles

Maven profiles and Spring profiles solve different problems at different stages of the application lifecycle. Maven profiles are build-time tools. When I run mvn package -Pprod, Maven decides what goes into the JAR — which dependencies to include, which plugins to run, how to filter property files. The output is a JAR that's already customized for production. Spring profiles, on the other hand, are runtime tools. The same JAR can start with different Spring profiles active depending on environment variables. So if I run java -jar app.jar --spring.profiles.active equals prod, Spring loads the production beans and configuration classes. If I run it with dev, Spring loads the development beans instead. Here's a concrete example. Let's say I'm working on an order processing service. I'd use a Maven profile to include the Oracle JDBC driver dependency in production builds but use H2 for local development. That's a build decision — the two JARs literally have different dependencies inside them. Then I'd use Spring profiles to switch between a ProductionDataSource bean with connection pooling and a DevDataSource bean with an in-memory database. Both beans exist in the code, but Spring activates one or the other depending on the active profile at runtime. A common mistake is using Maven profiles to package environment-specific config like database URLs into the JAR. That's wrong because it violates the build once, deploy everywhere principle. You should build one JAR and use Spring profiles or environment variables to inject config when the app starts. Maven profiles are for what you build. Spring profiles are for how it runs. They're complementary, not interchangeable.