On 27 January 2012 21:15, Woonsan Ko <[email protected]> wrote: > > > > > ----- Original Message ----- > > From: "Carlucci, Tony" <[email protected]> > > To: "[email protected]" <[email protected]>; > Woonsan Ko <[email protected]> > > Cc: > > Sent: Friday, January 27, 2012 2:17 PM > > Subject: RE: Maven Build and Deploy Best Practices > > > > > >> -----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... > > 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > >
