>-----Original Message----- >From: Woonsan Ko [mailto:[email protected]] >Sent: Friday, January 27, 2012 1:42 PM >To: [email protected] >Subject: Re: Maven Build and Deploy Best Practices > >Hi Tony, > >>________________________________ >> From: "Carlucci, Tony" <[email protected]> >>To: "[email protected]" <[email protected]> >>Sent: Friday, January 27, 2012 11:33 AM >>Subject: RE: Maven Build and Deploy Best Practices >> >> >>>-----Original Message----- >>>From: marijan milicevic [mailto:[email protected]] >>>Sent: Friday, January 27, 2012 10:58 AM >>>To: [email protected] >>>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 >>>> >>>> >>>> >>>> >>>> >> >> >> >>
