I do my best to avoid needing a separate build per environment. A release is a release, and while reproducibility is not the issue, I find it silly to do so.
In my customer work, I found two key strategies that have worked well, both from "new system" and streamlining an existing system: Option 3 -------- Use container configuration. Just get the DataSource for a connection. For other info, set properties and/or servlet context params. Option 4 -------- Include all property files in the artifact, and the environment determines which one is used: - Have a base name for the set of property files, e.g. app.properties. - Set an environment variable on each runtime environment, e.g. APP_ENV=dev, APP_ENV=test, APP_ENV=prod. - Have the code load props from app_${APP_ENV}.properties. Or use the env var as a directory name for a collection of env specific files, e.g. ${APP_ENV}/app.properties. -----Original Message----- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 6:39 AM To: Maven Users List Subject: What is the Best practice for generating variations of an artifacts? Hi, I've never found a good answer to this use case so far so I'm curious about how others have implemented it. Imagine a project that generates a WAR. This WAR contains a config file (say in WEB-INF/classes) that configures connection parameters for the database. Now imagine that your project wants to support several databases and you want the ability to build for a given database. I see 2 options: Option 1 ----------- * Use filtering * Use profiles to set the values for the different databases Issues: * In order to differentiate the generate WAR file name you'll need to use <finalName> but the value set there won't be used for install/ deploy which means that the WAR files users will see will always be the same. Idea for future: * It would be nice if Maven had a <classifier> element under <project> so that it would be possible to generate an artifact with a classifier. Option 2 ----------- * Create one module per database, under a parent module * Create profiles in the parent module to conditionally include the <module> to be built Issues: * Very heavy (one module per database) especially when the only difference between the generated artifacts is only 3 lines in a config file * Need a way to share common configuration between the modules, in order to prevent duplication. For example if the config files only contains 3 lines that are different for each database and there are 100 lines in total, you don't want to duplicate the 97 lines in as many modules as you have databases What do people do? Is there some plan to support this use case in a better fashion in the future? Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]