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#a11963274
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
