That's correct. My mistate. I thought i replied to your msg last night - but
my reply seems to have disapered.
Details of my new approach, and issues can be found here:
http://forum.springframework.org/showthread.php?t=42314
I will change it to use multiple PropertyPlaceholderConfigurer beans. One to
load the environment setting from a properties file external to my artefact
(this is instead of your method of passing it in as a system property) and a
2nd to load the appropriate environment settings.
One advantage of using an external properties file instead of a system
property (which btw, you could set to override the configuration file
property), is that you can use a monitoring implementation of
PropertyPlaceholderConfigurer (there is one free on the net) which could
potentially refresh your settings - i.e. redirect your application, live, to
a different environment.
jp4 wrote:
>
> Wouldn't this still result in different artifacts for different
> environments? If so, this is what I want to avoid. I would like my
> artifacts to be environment agnostic. If you are building a single
> artifact, perhaps you could explain how this works.
>
> Thanks,
>
> John
>
> Antony Stubbs wrote:
>>
>> Even better - you can do away with the system property requirement if you
>> use Maven Filtering with spring. That way you can set the parameters at
>> build time, and not have to depend on a system parameter existing.
>>
>> e.g. you use maven filtering to replace ${dev} inside your spring xml
>> files with the parameters value during build, instead of spring having to
>> resolve it.
>>
>>
>>
>> jp4 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#a12026756
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
