Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using Maven for multiple deployment environment (production/development)

Tags:

maven-2

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

Currently I create an Ant script to create different war files - one for production and one for development, using these 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 by plugging in the properties file

Is there something like that in maven (different war created depending on the configuration)?

if so, how do i do that?

i tried mvn warbut it just creates a war

like image 260
Titi Wangsa bin Damhore Avatar asked Jul 19 '09 06:07

Titi Wangsa bin Damhore


People also ask

How do I deploy a Maven project to production?

xml , create a tag in the VCS, promote the versions to a new SNAPSHOT (e.g. 1.1-SNAPSHOT) in the pom. xml , commit the new pom. xml in the VCS. The entire process require some work but this can be automated using the Maven Release Plugin.

What are the key advantages of Maven?

Advantages of using Maven:One can easily build their project to jar,war etc. as per their requirements using Maven. Maven makes easy to start project in different environments and one doesn't needs to handle the dependencies injection, builds, processing, etc. Adding a new dependency is very easy.

Is Maven used for deployment?

The maven deploy plugin can be used to deploy either files or projects to the remote repository for sharing it with other developers and projects.


2 Answers

I prefer use maven profiles for this situation. For example we have 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 that case, I dont need to update every time pom.xml for new files. In IDE simply switch profiles, or use -P flag from command line.

UPD: what to do if some properties are the same for configurations? Make the configuration like this:

<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> 

Common part will be stored in src/main/resources and other configs will be in appropriate folders in config directory.

like image 147
m1ld Avatar answered Oct 10 '22 11:10

m1ld


FYI best practice is to not have to rebuild your artifact for different environments - as that does not lead to re-produce-able builds, and other things could potentially change when rebuilding. I.e. using resource-filtering, as suggested above, only works when re-building your project.

When you graduate an artifact from dev to test or acceptance test to production - you do not want to have to rebuild.

What you want to do, is actually have your configuration dynamic, dependent on run-time variables. I.e. different spring setups or properties files for different environments e.g:

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

Then you can switch between these configurations using run-time variables and Spring's PropertyPlaceholderConfigurer.

You can also actually use different spring configuration files as well, as I've done in the past, for more complex setups.

I also suggest you leave your 'default' setup as production - so that if you deploy to production, you don't need to worry if you forget to set the environment variable.

like image 35
Antony Stubbs Avatar answered Oct 10 '22 11:10

Antony Stubbs