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_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 >>> >>> >>> >>> >>> > > > >
