Using Maven for a Multiple Deployment Environment (Production / Development)

Question

I have a web application in Maven with the default directory structure. No problems. The default directory structure has some property files that point to my localhost database.

I am currently creating an Ant script to create different military files - one for production and one for development using the following commands:

ant deploy-dev ant deploy-prod ant deploy-sit ant deploy-uat 

So basically they create a war file, and then update the war file, including the properties file

Is there something similar in maven (another war is created depending on the configuration)?

if so, how to do it?

I tried mvn war , but it just makes war

Answer 1

FYI's best practice is not to rebuild your artifact for different environments, as this does not lead to the restoration of prefabricated structures, and other things can potentially change during rebuilding. That is, using resource filtering, as suggested above, only works when rebuilding your project.

When you finish an artifact from a developer to a test or production acceptance test, you don’t want to rebuild.

What you want to do actually has a dynamic configuration, depending on the run-time variables. That is, different spring settings or properties files for different environments, for example:

 db-dev.properties db-test.properties db-prod.properties 

Then you can switch between these configurations using runtime variables and spring PropertyPlaceholderConfigurer .

You can also use different spring configuration files, as I did in the past, for more complex settings.

I also suggest leaving the default setting as production — so that when you deploy to production, you don’t have to worry if you forget to set the environment variable.

Answer 2

I prefer to use maven profiles for this situation. For example, we have a directory structure:

 src / main / resources
 |
 + - local
 |  |
 |  `- specific.properties
 + - dev
    |
    `- specific.properties

In pom.xml, define two profiles:

 <profiles> <profile> <id>local</id> <activation> <activeByDefault>true</activeByDefault> </activation> <build> <resources> <resource> <directory>src/main/resources/local</directory> </resource> </resources> </build> </profile> <profile> <id>dev</id> <build> <resources> <resource> <directory>src/main/resources/dev</directory> </resource> </resources> </build> </profile> </profiles> 

In this case, I do not need to update pom.xml every time for new files. In the IDE, simply switch profiles or use the -P flag from the command line.

UPD : what if some properties are the same for configurations? Make the configuration as follows:

 <profiles> <profile> <id>local</id> <activation> <activeByDefault>true</activeByDefault> </activation> <build> <resources> <resource> <directory>src/main/resources</directory> </resource> <resource> <directory>src/main/config/local</directory> </resource> </resources> </build> </profile> <profile> <id>dev</id> <build> <resources> <resource> <directory>src/main/resources</directory> </resource> <resource> <directory>src/main/config/dev</directory> </resource> </resources> </build> </profile> </profiles> 

The common part will be saved in src/main/resources , and other configs will be in the corresponding folders in the configuration directory.

Answer 3

If you want to remove ant from your process, I would look at using assembly profiles with filters.

In this case, include your property files in the src / main / resources tree structure. Then parameterize the properties file with filter properties such as this:

 jdbc.url=${filtered.jdbc.property} 

Then, src / main / filters create filter files based on profiles. so you can have dev-filters.properties sit-filters.properties, etc. They contain:

 filtered.jdbc.property=jdbc url here 

Then you configure the build profiles for each region where you set the env property, which indicates the specific region of your building. You can then configure the resource filter to use ${env}-filters.properties for each assembly. In addition, you can configure the military plugin to add the env property to your artifact so that you actually store 4 different artifacts in your repository under a different classifier.

Then you simply create an application with each profile. You must call the assembly for each profile, but it works well.

An example of some settings in POM:

 <build> <filters> <filter>src/main/filters/filter-${env}-application.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.1-beta-1</version> <executions> <execution> <phase>package</phase> <goals> <goal>war</goal> </goals> <configuration> <classifier>${env}</classifier> </configuration> </execution> </executions> </plugin> </plugins> </build> <profiles> <profile> <id>LOCAL</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <env>LOCAL</env> </properties> </profile> <profile> <id>DEV</id> <properties> <env>DEV</env> </properties> </profile> <profile> <id>UAT</id> <properties> <env>UAT</env> </properties> </profile> <profile> <id>PROD</id> <properties> <env>PROD</env> </properties> </profile> </profiles> 

In addition, the details of this blog post in which I initially found steps to accomplish this.

Answer 4

I handled this using the Spring PropertyPlaceholderConfigurer and included the property files in the pathpath and one on the file system:

 <context:property-placeholder location="classpath*:META-INF/spring/*.properties,file:myapp*.properties"/> 

If there is a myapp * .properties file in the current directory when the application starts (or tests run, etc.), it overrides the properties from the files baked in war / ear / whatever.

Answer 5

Here's this article about it on maven 2 using build profiles . It seems like it just delegates ant anyway through the antrun plugin, so you can even get away with reusing existing build.xml files.

Answer 6

This says very well that it uses build profiles like @seth -

http://maven.apache.org/guides/mini/guide-building-for-different-environments.html