I have found a solution that works well for me. I use spring in conjuction with a bootstrap variable called "env". When I start my container in development env=dev in production it's env=prod. I then use spring to resolve properties based on the environment. For example, a property file would look like this
url.dev=http://dev.foo.com url.qa=http://qa.foo.com url.prod=http://www.foo.com I then inject this property into a spring bean with something like this <bean id="test" class="...."> <property name="url"><value>${url.${env}}</value></property> </bean> This allows all of my deployable artifacts to be environment agnostic, the same war, ear, etc can be deployed to any environment as long as the System Property is set on the container. In addition, this solution has the added benefit of simplifying unit test cases as well. If you don't use spring, then this probably isn't right for you. If you are interested I can provide sample code, etc. Jo Vandermeeren wrote: > > Hi Vincent, > > I use filtering with profiles (option 1) and rebuild the entire project > when > I need another configuration. > This is far from ideal.. > > Perhaps you could keep your runtime configuration in a separate module and > include the one you need as a dependency by activating a profile? > I like your idea with the classifier approach.. > > Cheers > Jo > > On 3/16/07, Vincent Massol <[EMAIL PROTECTED]> wrote: >> >> 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] >> >> > > -- View this message in context: http://www.nabble.com/What-is-the-Best-practice-for-generating-variations-of-an-artifacts--tf3414040s177.html#a10200077 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
