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