You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Carlucci, Tony" <ac...@mitre.org> on 2012/01/27 16:38:51 UTC
Maven Build and Deploy Best Practices
Hello,
We have been trying to determine the best way to build and deploy Rave based projects internally (in reality Maven 3 projects). Our current software migration process requires us to build a "generic" artifact of any application (without any environment specific properties) that can be deployed to any of our environments (dev, qa, prod, etc). The deploy process essentially retrieves the generic artifact and applies the environment specific settings (like urls to external resources, email addresses, LDAP urls, etc), and copies the environment-specific WAR to the appropriate server.
The majority of our applications are Ant based and we have a neat home-grown Task that performs string token substitutions of our files which contain placeholders for the environment specific values. This lets us customize any file in our application (.properties, application-context.xml, web.xml, etc) during the deploy process.
Our question is: how do we best do this for Maven 3 based projects? We need to build the "generic" artifact (which gets stored in our Software Repository application) and then apply the environment specific properties at deploy time. I know Maven supports profiles but these seem to be needed during the build/packaging phase, and would undoubtedly place an environment specific artifact in both the Maven repository and our internal artifact repository tool. Is it better to externalize all environment specific properties outside of the WAR?
This seems like a problem that has already been solved and we are hoping the Rave community would have some experience in this area.
Thanks, Tony
Re: Maven Build and Deploy Best Practices
Posted by marijan milicevic <m....@onehippo.com>.
On 01/27/2012 05:33 PM, Carlucci, Tony wrote:
>> -----Original Message-----
>> From: marijan milicevic [mailto:m.milicevic@onehippo.com]
>> Sent: Friday, January 27, 2012 10:58 AM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: Maven Build and Deploy Best Practices
>>
>> Hi Tony,
>>
>> On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
>>> Hello,
>>>
>>>
>>>
>>> We have been trying to determine the best way to build and deploy Rave
>> based projects internally (in reality Maven 3 projects). Our current software
>> migration process requires us to build a "generic" artifact of any application
>> (without any environment specific properties) that can be deployed to any of
>> our environments (dev, qa, prod, etc). The deploy process essentially
>> retrieves the generic artifact and applies the environment specific settings
>> (like urls to external resources, email addresses, LDAP urls, etc), and copies
>> the environment-specific WAR to the appropriate server.
>>>
>>>
>>> The majority of our applications are Ant based and we have a neat home-
>> grown Task that performs string token substitutions of our files which contain
>> placeholders for the environment specific values. This lets us customize any
>> file in our application (.properties, application-context.xml, web.xml, etc)
>> during the deploy process.
>>>
>>>
>>> Our question is: how do we best do this for Maven 3 based projects? We
>> need to build the "generic" artifact (which gets stored in our Software
>> Repository application) and then apply the environment specific properties at
>> deploy time. I know Maven supports profiles but these seem to be needed
>> during the build/packaging phase, and would undoubtedly place an
>> environment specific artifact in both the Maven repository and our internal
>> artifact repository tool. Is it better to externalize all environment specific
>> properties outside of the WAR?
>> we (at Hippo) mostly use this approach: storing stuff outside of the WAR
>> (albeit for different product). What we try to avoid is to many
>> differences within appication-contex, web.xml etc. files and use
>> properties as much as possible, actually, in most cases those files are
>> identical for all environments.
>>
>> A lot of the security issues is also solved by applying this (e.g. no
>> user names nor passwords are stored on developers machines /svn/git etc).
>> I think Rave can pretty much be used this way.
>>
>> cheers
>> marijan
> Thanks for the input Marijan. A few follow up questions:
>
> 1) How do you reference the external properties file from the application? Would you reference it from, say, a spring properties bean config that references it via file: instead of classpath? (like file://directory/outside/webapp/thatsonallourservers)
I'll need to ask our sys admins, but I believe it is a combination of
symbolic links/system wide properties and application server properties
(think of JNDI, e.g. mail/Session deffinition, tomcat/conf/context.xml
file etc)
> 2) How do you manage these files from a version/source control perspective? Do you store them in a separate sub-folder of the project that is not used at all by your package mechanism (meaning ant or maven does use/see these files at all)? Do you keep multiple environment-specific versions of your properties files around, or do you have some process that takes a single "template" and applies the environment specific values to them
we only store things needed for local development. We have some
configuration stored into our local repository which is meant for
production/test servers, but his part is very Hippo (our CMS product)
specific.
>
> 3) How do you deploy the files if they change? Do you deploy them separately from your WAR deploy process?
no. normally some properties rarely change (like DB connection stuff
etc.). Application specific properties are mentioned in release notes.
So, yes, there is a "human factor" involved e.g. you need to keep
release notes updated.
I am also interested how other people are dealing with this issues..
cheers,
marijan
>>
>>>
>>> This seems like a problem that has already been solved and we are hoping
>> the Rave community would have some experience in this area.
>>>
>>>
>>> Thanks, Tony
>>>
>>>
>>>
>>>
>>>
Re: Maven Build and Deploy Best Practices
Posted by Woonsan Ko <wo...@yahoo.com>.
Hi Jasha,
>> >
>> > Interesting idea about using a container-supplied system property to
>> control
>> > which external file to read the properties from...
>>
>> Also, the following seems possible with commons configuration:
>>
>> <!-- classpath:portal.xml loaded by spring -->
>> <configuration>
>> <override>
>> <portal>
>> <opensocial_engine>
>> <root>localhost:8080</root>
>> </opensocial_engine>
>> </portal>
>> <system/>
>>
>>
> <propertiesfileName="${portal.config}/portal-${portal.env}.properties"
> config-optional="true"/>
>> </override>
>> <configuration>
>>
>>
>> So, you can have default properties like portal.opensocial_engine.root,
>> and those properties can be overriden by optionally provided external
>> properties file.
>>
>>
> Good suggestion Woonsan (as always)! Far better than the properties
> override I once added.
>
Thanks for the comment!
I have just realized that your OverridablePropertyPlaceholderConfigurer already supported properties file path overriding by system property.
But, as you know, when there are multiple properties files for each applicationContext, it will be more convenient to use commons-configuration because we can reduce system properties.
So, I think I can i) create a JIRA issue for this and ii) add a unit test to simulate this concept first for your review. (I don't think we have to rush into changing the current solution now.)
Does this sound okay?
Cheers,
Woonsan
Re: Maven Build and Deploy Best Practices
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 27 January 2012 21:15, Woonsan Ko <wo...@yahoo.com> wrote:
>
>
>
>
> ----- Original Message -----
> > From: "Carlucci, Tony" <ac...@mitre.org>
> > To: "rave-dev@incubator.apache.org" <ra...@incubator.apache.org>;
> Woonsan Ko <wo...@apache.org>
> > Cc:
> > Sent: Friday, January 27, 2012 2:17 PM
> > Subject: RE: Maven Build and Deploy Best Practices
> >
> >
> >> -----Original Message-----
> >> From: Woonsan Ko [mailto:woon_san@yahoo.com]
> >> Sent: Friday, January 27, 2012 1:42 PM
> >> To: rave-dev@incubator.apache.org
> >> Subject: Re: Maven Build and Deploy Best Practices
> >>
> >> Hi Tony,
> >>
> >>> ________________________________
> >>> From: "Carlucci, Tony" <ac...@mitre.org>
> >>> To: "rave-dev@incubator.apache.org"
> > <ra...@incubator.apache.org>
> >>> Sent: Friday, January 27, 2012 11:33 AM
> >>> Subject: RE: Maven Build and Deploy Best Practices
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: marijan milicevic [mailto:m.milicevic@onehippo.com]
> >>>> Sent: Friday, January 27, 2012 10:58 AM
> >>>> To: rave-dev@incubator.apache.org
> >>>> Subject: Re: Maven Build and Deploy Best Practices
> >>>>
> >>>> Hi Tony,
> >>>>
> >>>> On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> We have been trying to determine the best way to build and
> > deploy Rave
> >>>> based projects internally (in reality Maven 3 projects). Our
> > current
> >> software
> >>>> migration process requires us to build a "generic"
> > artifact of any application
> >>>> (without any environment specific properties) that can be deployed
> > to any
> >> of
> >>>> our environments (dev, qa, prod, etc). The deploy process
> > essentially
> >>>> retrieves the generic artifact and applies the environment specific
> > settings
> >>>> (like urls to external resources, email addresses, LDAP urls, etc),
> > and copies
> >>>> the environment-specific WAR to the appropriate server.
> >>>>>
> >>>>>
> >>>>>
> >>>>> The majority of our applications are Ant based and we have a
> > neat home-
> >>>> grown Task that performs string token substitutions of our files
> > which
> >> contain
> >>>> placeholders for the environment specific values. This lets us
> > customize
> >> any
> >>>> file in our application (.properties, application-context.xml,
> > web.xml, etc)
> >>>> during the deploy process.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Our question is: how do we best do this for Maven 3 based
> > projects? We
> >>>> need to build the "generic" artifact (which gets stored in
> > our Software
> >>>> Repository application) and then apply the environment specific
> > properties
> >> at
> >>>> deploy time. I know Maven supports profiles but these seem to be
> >> needed
> >>>> during the build/packaging phase, and would undoubtedly place an
> >>>> environment specific artifact in both the Maven repository and our
> > internal
> >>>> artifact repository tool. Is it better to externalize all
> > environment specific
> >>>> properties outside of the WAR?
> >>>> we (at Hippo) mostly use this approach: storing stuff outside of the
> > WAR
> >>>> (albeit for different product). What we try to avoid is to many
> >>>> differences within appication-contex, web.xml etc. files and use
> >>>> properties as much as possible, actually, in most cases those files
> > are
> >>>> identical for all environments.
> >>>>
> >>>> A lot of the security issues is also solved by applying this (e.g.
> > no
> >>>> user names nor passwords are stored on developers machines /svn/git
> >> etc).
> >>>> I think Rave can pretty much be used this way.
> >>>>
> >>>> cheers
> >>>> marijan
> >>>
> >>> Thanks for the input Marijan. A few follow up questions:
> >>>
> >>> 1) How do you reference the external properties file from the
> >> application? Would you reference it from, say, a spring properties bean
> > config
> >> that references it via file: instead of classpath? (like
> >> file://directory/outside/webapp/thatsonallourservers)
> >>
> >> In our content-based application framework (HST-2), we used Commons-
> >> configuration instead.
> >> We hook spring application context to use the commons-configuration's
> >> configuration object by adding a BeanFactoryPostProcessor.
> >> Commons-configuration provides a lot of option. For example, you may
> >> include all the system properties in the configuration file just by
> adding
> >> <system/> element.
> >> Also, a commons configuration xml can use property variables and include
> >> multiple properties files.
> >> See http://commons.apache.org/configuration/userguide/howto_configurati
> >> onbuilder.html for more detail.
> >> So, someone appended a system property when running tomcat to indicate
> >> which properties file should be loaded. In that way, he used different
> >> properties file based on dtap.
> >>
> >>>
> >>> 2) How do you manage these files from a version/source control
> >> perspective? Do you store them in a separate sub-folder of the project
> that
> > is
> >> not used at all by your package mechanism (meaning ant or maven does
> >> use/see these files at all)? Do you keep multiple environment-specific
> >> versions of your properties files around, or do you have some process
> that
> >> takes a single "template" and applies the environment specific
> > values to them
> >>>
> >>
> >> One solution is to have a conf directory with multiple properties files
> > based on
> >> dtap, and have sysadmin to append a system property in the command.
> >> e.g., -Dportal.env=prod
> >> Then, the commons configuration could read that like the following:
> >>
> >> <configuration>
> >> <!-- Load the system properties -->
> >> <system/>
> >> <propertiesfileName="${catalina.home}/conf/portal-
> >> ${portal.env}.properties"/>
> >> </configuration>
> >>
> >>> 3) How do you deploy the files if they change? Do you deploy them
> >> separately from your WAR deploy process?
> >>
> >> We can keep the files separately from the war. The war may contain a
> >> common configuration which doesn't need to change at all as shown above.
> >>
> >> However, we will probably need to change the current spring
> configuration to
> >> use commons-configuration.
> >> Spring Modules seems to have already provided that feature:
> >>
> http://stackoverflow.com/questions/3163838/propertyplaceholderconfigurer
> >> -reads-from-xml-file-apache-commons-configuration
> >>
> >>
> >> Cheers,
> >>
> >> Woonsan
> >
> > Interesting idea about using a container-supplied system property to
> control
> > which external file to read the properties from...
>
> Also, the following seems possible with commons configuration:
>
> <!-- classpath:portal.xml loaded by spring -->
> <configuration>
> <override>
> <portal>
> <opensocial_engine>
> <root>localhost:8080</root>
> </opensocial_engine>
> </portal>
> <system/>
>
> <propertiesfileName="${portal.config}/portal-${portal.env}.properties" config-optional="true"/>
> </override>
> <configuration>
>
>
> So, you can have default properties like portal.opensocial_engine.root,
> and those properties can be overriden by optionally provided external
> properties file.
>
>
Good suggestion Woonsan (as always)! Far better than the properties
override I once added.
Jasha
> Regards,
>
> Woonsan
> >
> >>
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> This seems like a problem that has already been solved and we
> > are
> >> hoping
> >>>> the Rave community would have some experience in this area.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks, Tony
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
>
Re: Maven Build and Deploy Best Practices
Posted by Woonsan Ko <wo...@yahoo.com>.
----- Original Message -----
> From: "Carlucci, Tony" <ac...@mitre.org>
> To: "rave-dev@incubator.apache.org" <ra...@incubator.apache.org>; Woonsan Ko <wo...@apache.org>
> Cc:
> Sent: Friday, January 27, 2012 2:17 PM
> Subject: RE: Maven Build and Deploy Best Practices
>
>
>> -----Original Message-----
>> From: Woonsan Ko [mailto:woon_san@yahoo.com]
>> Sent: Friday, January 27, 2012 1:42 PM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: Maven Build and Deploy Best Practices
>>
>> Hi Tony,
>>
>>> ________________________________
>>> From: "Carlucci, Tony" <ac...@mitre.org>
>>> To: "rave-dev@incubator.apache.org"
> <ra...@incubator.apache.org>
>>> Sent: Friday, January 27, 2012 11:33 AM
>>> Subject: RE: Maven Build and Deploy Best Practices
>>>
>>>
>>>> -----Original Message-----
>>>> From: marijan milicevic [mailto:m.milicevic@onehippo.com]
>>>> Sent: Friday, January 27, 2012 10:58 AM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: Maven Build and Deploy Best Practices
>>>>
>>>> Hi Tony,
>>>>
>>>> On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> We have been trying to determine the best way to build and
> deploy Rave
>>>> based projects internally (in reality Maven 3 projects). Our
> current
>> software
>>>> migration process requires us to build a "generic"
> artifact of any application
>>>> (without any environment specific properties) that can be deployed
> to any
>> of
>>>> our environments (dev, qa, prod, etc). The deploy process
> essentially
>>>> retrieves the generic artifact and applies the environment specific
> settings
>>>> (like urls to external resources, email addresses, LDAP urls, etc),
> and copies
>>>> the environment-specific WAR to the appropriate server.
>>>>>
>>>>>
>>>>>
>>>>> The majority of our applications are Ant based and we have a
> neat home-
>>>> grown Task that performs string token substitutions of our files
> which
>> contain
>>>> placeholders for the environment specific values. This lets us
> customize
>> any
>>>> file in our application (.properties, application-context.xml,
> web.xml, etc)
>>>> during the deploy process.
>>>>>
>>>>>
>>>>>
>>>>> Our question is: how do we best do this for Maven 3 based
> projects? We
>>>> need to build the "generic" artifact (which gets stored in
> our Software
>>>> Repository application) and then apply the environment specific
> properties
>> at
>>>> deploy time. I know Maven supports profiles but these seem to be
>> needed
>>>> during the build/packaging phase, and would undoubtedly place an
>>>> environment specific artifact in both the Maven repository and our
> internal
>>>> artifact repository tool. Is it better to externalize all
> environment specific
>>>> properties outside of the WAR?
>>>> we (at Hippo) mostly use this approach: storing stuff outside of the
> WAR
>>>> (albeit for different product). What we try to avoid is to many
>>>> differences within appication-contex, web.xml etc. files and use
>>>> properties as much as possible, actually, in most cases those files
> are
>>>> identical for all environments.
>>>>
>>>> A lot of the security issues is also solved by applying this (e.g.
> no
>>>> user names nor passwords are stored on developers machines /svn/git
>> etc).
>>>> I think Rave can pretty much be used this way.
>>>>
>>>> cheers
>>>> marijan
>>>
>>> Thanks for the input Marijan. A few follow up questions:
>>>
>>> 1) How do you reference the external properties file from the
>> application? Would you reference it from, say, a spring properties bean
> config
>> that references it via file: instead of classpath? (like
>> file://directory/outside/webapp/thatsonallourservers)
>>
>> In our content-based application framework (HST-2), we used Commons-
>> configuration instead.
>> We hook spring application context to use the commons-configuration's
>> configuration object by adding a BeanFactoryPostProcessor.
>> Commons-configuration provides a lot of option. For example, you may
>> include all the system properties in the configuration file just by adding
>> <system/> element.
>> Also, a commons configuration xml can use property variables and include
>> multiple properties files.
>> See http://commons.apache.org/configuration/userguide/howto_configurati
>> onbuilder.html for more detail.
>> So, someone appended a system property when running tomcat to indicate
>> which properties file should be loaded. In that way, he used different
>> properties file based on dtap.
>>
>>>
>>> 2) How do you manage these files from a version/source control
>> perspective? Do you store them in a separate sub-folder of the project that
> is
>> not used at all by your package mechanism (meaning ant or maven does
>> use/see these files at all)? Do you keep multiple environment-specific
>> versions of your properties files around, or do you have some process that
>> takes a single "template" and applies the environment specific
> values to them
>>>
>>
>> One solution is to have a conf directory with multiple properties files
> based on
>> dtap, and have sysadmin to append a system property in the command.
>> e.g., -Dportal.env=prod
>> Then, the commons configuration could read that like the following:
>>
>> <configuration>
>> <!-- Load the system properties -->
>> <system/>
>> <propertiesfileName="${catalina.home}/conf/portal-
>> ${portal.env}.properties"/>
>> </configuration>
>>
>>> 3) How do you deploy the files if they change? Do you deploy them
>> separately from your WAR deploy process?
>>
>> We can keep the files separately from the war. The war may contain a
>> common configuration which doesn't need to change at all as shown above.
>>
>> However, we will probably need to change the current spring configuration to
>> use commons-configuration.
>> Spring Modules seems to have already provided that feature:
>> http://stackoverflow.com/questions/3163838/propertyplaceholderconfigurer
>> -reads-from-xml-file-apache-commons-configuration
>>
>>
>> Cheers,
>>
>> Woonsan
>
> Interesting idea about using a container-supplied system property to control
> which external file to read the properties from...
Also, the following seems possible with commons configuration:
<!-- classpath:portal.xml loaded by spring -->
<configuration>
<override>
<portal>
<opensocial_engine>
<root>localhost:8080</root>
</opensocial_engine>
</portal>
<system/>
<propertiesfileName="${portal.config}/portal-${portal.env}.properties" config-optional="true"/>
</override>
<configuration>
So, you can have default properties like portal.opensocial_engine.root, and those properties can be overriden by optionally provided external properties file.
Regards,
Woonsan
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> This seems like a problem that has already been solved and we
> are
>> hoping
>>>> the Rave community would have some experience in this area.
>>>>>
>>>>>
>>>>>
>>>>> Thanks, Tony
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
RE: Maven Build and Deploy Best Practices
Posted by "Carlucci, Tony" <ac...@mitre.org>.
>-----Original Message-----
>From: Woonsan Ko [mailto:woon_san@yahoo.com]
>Sent: Friday, January 27, 2012 1:42 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: Maven Build and Deploy Best Practices
>
>Hi Tony,
>
>>________________________________
>> From: "Carlucci, Tony" <ac...@mitre.org>
>>To: "rave-dev@incubator.apache.org" <ra...@incubator.apache.org>
>>Sent: Friday, January 27, 2012 11:33 AM
>>Subject: RE: Maven Build and Deploy Best Practices
>>
>>
>>>-----Original Message-----
>>>From: marijan milicevic [mailto:m.milicevic@onehippo.com]
>>>Sent: Friday, January 27, 2012 10:58 AM
>>>To: rave-dev@incubator.apache.org
>>>Subject: Re: Maven Build and Deploy Best Practices
>>>
>>>Hi Tony,
>>>
>>>On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
>>>> Hello,
>>>>
>>>>
>>>>
>>>> We have been trying to determine the best way to build and deploy Rave
>>>based projects internally (in reality Maven 3 projects). Our current
>software
>>>migration process requires us to build a "generic" artifact of any application
>>>(without any environment specific properties) that can be deployed to any
>of
>>>our environments (dev, qa, prod, etc). The deploy process essentially
>>>retrieves the generic artifact and applies the environment specific settings
>>>(like urls to external resources, email addresses, LDAP urls, etc), and copies
>>>the environment-specific WAR to the appropriate server.
>>>>
>>>>
>>>>
>>>> The majority of our applications are Ant based and we have a neat home-
>>>grown Task that performs string token substitutions of our files which
>contain
>>>placeholders for the environment specific values. This lets us customize
>any
>>>file in our application (.properties, application-context.xml, web.xml, etc)
>>>during the deploy process.
>>>>
>>>>
>>>>
>>>> Our question is: how do we best do this for Maven 3 based projects? We
>>>need to build the "generic" artifact (which gets stored in our Software
>>>Repository application) and then apply the environment specific properties
>at
>>>deploy time. I know Maven supports profiles but these seem to be
>needed
>>>during the build/packaging phase, and would undoubtedly place an
>>>environment specific artifact in both the Maven repository and our internal
>>>artifact repository tool. Is it better to externalize all environment specific
>>>properties outside of the WAR?
>>>we (at Hippo) mostly use this approach: storing stuff outside of the WAR
>>>(albeit for different product). What we try to avoid is to many
>>>differences within appication-contex, web.xml etc. files and use
>>>properties as much as possible, actually, in most cases those files are
>>>identical for all environments.
>>>
>>>A lot of the security issues is also solved by applying this (e.g. no
>>>user names nor passwords are stored on developers machines /svn/git
>etc).
>>>I think Rave can pretty much be used this way.
>>>
>>>cheers
>>>marijan
>>
>>Thanks for the input Marijan. A few follow up questions:
>>
>>1) How do you reference the external properties file from the
>application? Would you reference it from, say, a spring properties bean config
>that references it via file: instead of classpath? (like
>file://directory/outside/webapp/thatsonallourservers)
>
>In our content-based application framework (HST-2), we used Commons-
>configuration instead.
>We hook spring application context to use the commons-configuration's
>configuration object by adding a BeanFactoryPostProcessor.
>Commons-configuration provides a lot of option. For example, you may
>include all the system properties in the configuration file just by adding
><system/> element.
>Also, a commons configuration xml can use property variables and include
>multiple properties files.
>See http://commons.apache.org/configuration/userguide/howto_configurati
>onbuilder.html for more detail.
>So, someone appended a system property when running tomcat to indicate
>which properties file should be loaded. In that way, he used different
>properties file based on dtap.
>
>>
>>2) How do you manage these files from a version/source control
>perspective? Do you store them in a separate sub-folder of the project that is
>not used at all by your package mechanism (meaning ant or maven does
>use/see these files at all)? Do you keep multiple environment-specific
>versions of your properties files around, or do you have some process that
>takes a single "template" and applies the environment specific values to them
>>
>
>One solution is to have a conf directory with multiple properties files based on
>dtap, and have sysadmin to append a system property in the command.
>e.g., -Dportal.env=prod
>Then, the commons configuration could read that like the following:
>
><configuration>
> <!-- Load the system properties -->
> <system/>
> <propertiesfileName="${catalina.home}/conf/portal-
>${portal.env}.properties"/>
></configuration>
>
>>3) How do you deploy the files if they change? Do you deploy them
>separately from your WAR deploy process?
>
>We can keep the files separately from the war. The war may contain a
>common configuration which doesn't need to change at all as shown above.
>
>However, we will probably need to change the current spring configuration to
>use commons-configuration.
>Spring Modules seems to have already provided that feature:
>http://stackoverflow.com/questions/3163838/propertyplaceholderconfigurer
>-reads-from-xml-file-apache-commons-configuration
>
>
>Cheers,
>
>Woonsan
Interesting idea about using a container-supplied system property to control which external file to read the properties from...
>
>>
>>>
>>>
>>>>
>>>>
>>>> This seems like a problem that has already been solved and we are
>hoping
>>>the Rave community would have some experience in this area.
>>>>
>>>>
>>>>
>>>> Thanks, Tony
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
Re: Maven Build and Deploy Best Practices
Posted by Woonsan Ko <wo...@yahoo.com>.
Hi Tony,
>________________________________
> From: "Carlucci, Tony" <ac...@mitre.org>
>To: "rave-dev@incubator.apache.org" <ra...@incubator.apache.org>
>Sent: Friday, January 27, 2012 11:33 AM
>Subject: RE: Maven Build and Deploy Best Practices
>
>
>>-----Original Message-----
>>From: marijan milicevic [mailto:m.milicevic@onehippo.com]
>>Sent: Friday, January 27, 2012 10:58 AM
>>To: rave-dev@incubator.apache.org
>>Subject: Re: Maven Build and Deploy Best Practices
>>
>>Hi Tony,
>>
>>On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
>>> Hello,
>>>
>>>
>>>
>>> We have been trying to determine the best way to build and deploy Rave
>>based projects internally (in reality Maven 3 projects). Our current software
>>migration process requires us to build a "generic" artifact of any application
>>(without any environment specific properties) that can be deployed to any of
>>our environments (dev, qa, prod, etc). The deploy process essentially
>>retrieves the generic artifact and applies the environment specific settings
>>(like urls to external resources, email addresses, LDAP urls, etc), and copies
>>the environment-specific WAR to the appropriate server.
>>>
>>>
>>>
>>> The majority of our applications are Ant based and we have a neat home-
>>grown Task that performs string token substitutions of our files which contain
>>placeholders for the environment specific values. This lets us customize any
>>file in our application (.properties, application-context.xml, web.xml, etc)
>>during the deploy process.
>>>
>>>
>>>
>>> Our question is: how do we best do this for Maven 3 based projects? We
>>need to build the "generic" artifact (which gets stored in our Software
>>Repository application) and then apply the environment specific properties at
>>deploy time. I know Maven supports profiles but these seem to be needed
>>during the build/packaging phase, and would undoubtedly place an
>>environment specific artifact in both the Maven repository and our internal
>>artifact repository tool. Is it better to externalize all environment specific
>>properties outside of the WAR?
>>we (at Hippo) mostly use this approach: storing stuff outside of the WAR
>>(albeit for different product). What we try to avoid is to many
>>differences within appication-contex, web.xml etc. files and use
>>properties as much as possible, actually, in most cases those files are
>>identical for all environments.
>>
>>A lot of the security issues is also solved by applying this (e.g. no
>>user names nor passwords are stored on developers machines /svn/git etc).
>>I think Rave can pretty much be used this way.
>>
>>cheers
>>marijan
>
>Thanks for the input Marijan. A few follow up questions:
>
>1) How do you reference the external properties file from the application? Would you reference it from, say, a spring properties bean config that references it via file: instead of classpath? (like file://directory/outside/webapp/thatsonallourservers)
In our content-based application framework (HST-2), we used Commons-configuration instead.
We hook spring application context to use the commons-configuration's configuration object by adding a BeanFactoryPostProcessor.
Commons-configuration provides a lot of option. For example, you may include all the system properties in the configuration file just by adding <system/> element.
Also, a commons configuration xml can use property variables and include multiple properties files.
See http://commons.apache.org/configuration/userguide/howto_configurationbuilder.html for more detail.
So, someone appended a system property when running tomcat to indicate which properties file should be loaded. In that way, he used different properties file based on dtap.
>
>2) How do you manage these files from a version/source control perspective? Do you store them in a separate sub-folder of the project that is not used at all by your package mechanism (meaning ant or maven does use/see these files at all)? Do you keep multiple environment-specific versions of your properties files around, or do you have some process that takes a single "template" and applies the environment specific values to them
>
One solution is to have a conf directory with multiple properties files based on dtap, and have sysadmin to append a system property in the command.
e.g., -Dportal.env=prod
Then, the commons configuration could read that like the following:
<configuration>
<!-- Load the system properties -->
<system/>
<propertiesfileName="${catalina.home}/conf/portal-${portal.env}.properties"/>
</configuration>
>3) How do you deploy the files if they change? Do you deploy them separately from your WAR deploy process?
We can keep the files separately from the war. The war may contain a common configuration which doesn't need to change at all as shown above.
However, we will probably need to change the current spring configuration to use commons-configuration.
Spring Modules seems to have already provided that feature:
http://stackoverflow.com/questions/3163838/propertyplaceholderconfigurer-reads-from-xml-file-apache-commons-configuration
Cheers,
Woonsan
>
>>
>>
>>>
>>>
>>> This seems like a problem that has already been solved and we are hoping
>>the Rave community would have some experience in this area.
>>>
>>>
>>>
>>> Thanks, Tony
>>>
>>>
>>>
>>>
>>>
>
>
>
>
RE: Maven Build and Deploy Best Practices
Posted by "Carlucci, Tony" <ac...@mitre.org>.
>-----Original Message-----
>From: marijan milicevic [mailto:m.milicevic@onehippo.com]
>Sent: Friday, January 27, 2012 10:58 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: Maven Build and Deploy Best Practices
>
>Hi Tony,
>
>On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
>> Hello,
>>
>>
>>
>> We have been trying to determine the best way to build and deploy Rave
>based projects internally (in reality Maven 3 projects). Our current software
>migration process requires us to build a "generic" artifact of any application
>(without any environment specific properties) that can be deployed to any of
>our environments (dev, qa, prod, etc). The deploy process essentially
>retrieves the generic artifact and applies the environment specific settings
>(like urls to external resources, email addresses, LDAP urls, etc), and copies
>the environment-specific WAR to the appropriate server.
>>
>>
>>
>> The majority of our applications are Ant based and we have a neat home-
>grown Task that performs string token substitutions of our files which contain
>placeholders for the environment specific values. This lets us customize any
>file in our application (.properties, application-context.xml, web.xml, etc)
>during the deploy process.
>>
>>
>>
>> Our question is: how do we best do this for Maven 3 based projects? We
>need to build the "generic" artifact (which gets stored in our Software
>Repository application) and then apply the environment specific properties at
>deploy time. I know Maven supports profiles but these seem to be needed
>during the build/packaging phase, and would undoubtedly place an
>environment specific artifact in both the Maven repository and our internal
>artifact repository tool. Is it better to externalize all environment specific
>properties outside of the WAR?
>we (at Hippo) mostly use this approach: storing stuff outside of the WAR
>(albeit for different product). What we try to avoid is to many
>differences within appication-contex, web.xml etc. files and use
>properties as much as possible, actually, in most cases those files are
>identical for all environments.
>
>A lot of the security issues is also solved by applying this (e.g. no
>user names nor passwords are stored on developers machines /svn/git etc).
>I think Rave can pretty much be used this way.
>
>cheers
>marijan
Thanks for the input Marijan. A few follow up questions:
1) How do you reference the external properties file from the application? Would you reference it from, say, a spring properties bean config that references it via file: instead of classpath? (like file://directory/outside/webapp/thatsonallourservers)
2) How do you manage these files from a version/source control perspective? Do you store them in a separate sub-folder of the project that is not used at all by your package mechanism (meaning ant or maven does use/see these files at all)? Do you keep multiple environment-specific versions of your properties files around, or do you have some process that takes a single "template" and applies the environment specific values to them
3) How do you deploy the files if they change? Do you deploy them separately from your WAR deploy process?
>
>
>>
>>
>> This seems like a problem that has already been solved and we are hoping
>the Rave community would have some experience in this area.
>>
>>
>>
>> Thanks, Tony
>>
>>
>>
>>
>>
Re: Maven Build and Deploy Best Practices
Posted by marijan milicevic <m....@onehippo.com>.
Hi Tony,
On 01/27/2012 04:38 PM, Carlucci, Tony wrote:
> Hello,
>
>
>
> We have been trying to determine the best way to build and deploy Rave based projects internally (in reality Maven 3 projects). Our current software migration process requires us to build a "generic" artifact of any application (without any environment specific properties) that can be deployed to any of our environments (dev, qa, prod, etc). The deploy process essentially retrieves the generic artifact and applies the environment specific settings (like urls to external resources, email addresses, LDAP urls, etc), and copies the environment-specific WAR to the appropriate server.
>
>
>
> The majority of our applications are Ant based and we have a neat home-grown Task that performs string token substitutions of our files which contain placeholders for the environment specific values. This lets us customize any file in our application (.properties, application-context.xml, web.xml, etc) during the deploy process.
>
>
>
> Our question is: how do we best do this for Maven 3 based projects? We need to build the "generic" artifact (which gets stored in our Software Repository application) and then apply the environment specific properties at deploy time. I know Maven supports profiles but these seem to be needed during the build/packaging phase, and would undoubtedly place an environment specific artifact in both the Maven repository and our internal artifact repository tool. Is it better to externalize all environment specific properties outside of the WAR?
we (at Hippo) mostly use this approach: storing stuff outside of the WAR
(albeit for different product). What we try to avoid is to many
differences within appication-contex, web.xml etc. files and use
properties as much as possible, actually, in most cases those files are
identical for all environments.
A lot of the security issues is also solved by applying this (e.g. no
user names nor passwords are stored on developers machines /svn/git etc).
I think Rave can pretty much be used this way.
cheers
marijan
>
>
> This seems like a problem that has already been solved and we are hoping the Rave community would have some experience in this area.
>
>
>
> Thanks, Tony
>
>
>
>
>