maven profiles or spring profiles?

Maven profiles would provide a build-time solution, while SpringFramework profiles would provide a runtime alternative. I think this is the first question one may ask himself: if he wants to have a single package that can be deployed in different environments, or if he wants the build tool to provide different packages according to the destination environment.

One thing to keep in mind is that many questions may arise if you have different packages deployed into different servers. In my workplace, for example, if I am deploying a package to correct a bug previously occurred in production environment, a company policy would state that the only acceptable scenario is that I have the same solution package in QA and in production servers.

If you need different artifacts then go with maven. If it is just a real configuration that can be configured AFTER the artefact is build then user Spring profiles.

As mentioned in the other replies: it all depends on how you work :)

What we came up with in the last years using maven and now the spring 3.1 profiles is this:

• we use the maven-release-plugin to cut releases. this causes issues with environments if we would use maven profiles since we would need to rebuild the release or at least the tag with every maven profile
• so we create on .war file for all environments and use the spring PropertyPlaceholderConfigurer to setup the application (or some JNDI resource depending on the customer). This allows to have only one maven release run.
• the spring profiles come in when environments differ as well. for example an authentication service that is not available on all environments. Here we stub that service and put it into a spring profile. We active the spring profiles in the properties that is read by the PropertyPlaceholderConfigurer we use anyway.

there are some nice tutorials around on how to do that:

• http://pio-tech.blogspot.ch/2012/01/using-spring-31-bean-definition.html
• http://steveschols.wordpress.com/2012/06/01/spring-3-1-unified-property-management-before-and-after/

we usually only use maven profiles to split the build into different parts for the developers and the continuous integration build. We don't actually use them for target environments anymore for the .war files. We still use maven profiles for automated database deployments, which differ more compared to the web-apps (amount of data, test-data, ...), but these are not delivered as a zip or so.

There are surely other ways to go. I dont think its the end of the story :)

But it may help.