Both of the below are good solutions. I've also seen folks use a run time based solution where a different set of properties is loaded based on an Environment Variable common to all servers.
Cody Fyler Lending Grid Build Team G=Lending Grid Builds (515) – 441 - 0814 -----Original Message----- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Wednesday, September 10, 2014 9:15 AM To: Maven Users List Subject: Re: Build once, deploy everywhere What you want to do is have your packaged software be independent of the environment it is deployed to. That way you know by checking the SHA1 of the artifact you can know it was the one that was tested by QA. So what you do is have your application read its configuration from an external source. One example is you could read the configuration from the JNDI environment (if you are deploying in a JavaEE server). Thus you can setup the dev environment with the DB servers, etc defined in JNDI and the same for QA, PROD, etc Another example is you could look for a .properties file on the classpath or at a well known location (perhaps the user home or something like that) The application should fail fast if any of the configuration settings are missing to help diagnose issues. There are many ways to skin this cat, but rebuilding an artifact for each environment should be considered a critical anti-pattern On 10 September 2014 15:03, Jan <raghure...@gmail.com> wrote: > Hi All, > > Does anyone using Maven as Build Once and deploy Everywhere method? > Like lets say i don't want to recompile my source code everytime for > different environment DEV,SIT,UAT & PROD. I want to do my compile and > package only at DEV then deploy the artifact to all mentioned > environment. Is this possible using Maven, is there any reference any one > could share with me Please. >
