You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Antony Stubbs <an...@gmail.com> on 2007/08/02 11:46:14 UTC
Re: What is the Best practice for generating variations of an
artifacts?
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 <vi...@massol.net> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/What-is-the-Best-practice-for-generating-variations-of-an-artifacts--tf3414040s177.html#a11961453
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: What is the Best practice for generating variations of an
artifacts?
Posted by Antony Stubbs <an...@gmail.com>.
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 <vi...@massol.net> 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: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: What is the Best practice for generating variations of an
artifacts?
Posted by jp4 <jo...@hnpsolutions.com>.
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 <vi...@massol.net> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org