Coming from a strong ANT background, that approach seems very familiar!
On 26/04/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
I think several of us would be interested in this approach. Some sample code etc would be great. Wayne On 4/26/07, jp4 <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- 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]
