maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Blaxland <>
Subject Re: Overriding properties for different build configurations
Date Wed, 29 Sep 2004 01:00:04 GMT
Thanks Jefferson,

That's pretty much what I wanted. Only issue with it is that I want to 
load these properties up in a plugin that I wrote (so as to standardize 
our build process a bit), but util:properties loads up the properties 
into the current jelly context, which means that the loaded properties 
only override the props in the plugin's context, not the parent context. 
In the end I got around it by manually setting the properties in the 
parent context:

  <preGoal name="build:start">
    <j:if test="not(empty(${props}))">
      <util:available file="${props}">
        <util:properties file="${props}" trim="true" var="override_props"/>
        <j:forEach var="prop" items="${override_props}">
            <j:set var="${prop.key}" value="${prop.value}" scope="parent"/>

I think there's a gotcha with this, in that if another plugin is loaded 
before "build:start" runs, and that plugin initializes a property, then 
that property will not be overridden by the properties in "props" 
because it will then be defined in that plugin's context. But I think 
this is good enough for our needs.

I think this would be a useful feature to add to maven.


Jefferson K. French wrote:

>Will something like this in your maven.xml work for you:
>  <preGoal name="build:start">
>    <j:if test="not(empty(${props}))">
>      <util:available file="${props}">
>        <util:properties file="${props}" trim="true" />
>     </util:available>
>    </j:if>
>  </preGoal>
>The above is typed from memory, but when Maven is invoked as:
>  maven release
>it should load your property file using Jelly, which will overwrite
>any previously defined properties with the same name.
>  Jeff
>On Tue, 28 Sep 2004, at 11:42:35 [GMT +0200] Gisbert Amm wrote:
>>Charles Blaxland wrote:
>>>Hi all,
>>>As I understand it, maven loads its properties from, 
>>>, $HOME/ and the "-D" defines on the 
>>>command line, in that order, where the last definition wins.  However I 
>>>find myself frequently in the situation where I want another level of 
>>>property overriding for building particular "configurations" of my project.
>>>Here's an example: when building for our production servers, we need to 
>>>"touch" the built files to match the timestamp of the production server 
>>>(GMT), however in our development environment we don't wish to do this.  
>>>The touch offset (eg: "-10") is defined in our build by a property 
>>>Now when building for our production machines, I could say:
>>>maven -Dtouch.offset=-10 release
>>>but if I have a lot of properties that need to be over-ridden, this 
>>>becomes unwieldly, and its easy to forget them.  Instead, I'd love to be 
>>>able to do something like:
>>>maven release
>>>where "" contains:
>>>touch.offset = -10
>>>and overrides all other properties (ie: it behaves as if you'd specified 
>>>those properties on the command line).
>>>Does anyone know if there's a way to do this?  Failing that, is there a 
>>>way that I can achieve the same end by programatically loading the 
>>>properties file in maven.xml?  Any suggestions appreciated.
>>Probably not the best solution, but one possible (for a UNIX-like 
>>environment, bash in this case):
>>maven -D$(cat | xargs | sed -e's/ / -D/g') release
>>Gisbert Amm

	Charles Blaxland — Solutions Engineer
*EB2 International Limited (London & Sydney)

*Grd Floor, 99 Stanley Street
Darlinghurst, NSW 2010
(ABN 27 095 125 045)

Tel: 	+61 (0) 2 8353 9113
Fax: 	+61 (0) 2 9380 9386
Mob: 	+61 (0) 403 957 442 <>

IMPORTANT: This electronic mail message and its attachments (if any) are 
confidential and may be legally privileged. If you are not the intended 
recipient, you may not legally copy, disclose or use the contents in any 
way and you should contact us immediately and destroy this message and 
any attachments.

This email is not guaranteed to be error-free, virus-free, or intact. 
The sender does not accept any liability for the effects the reception, 
or non-reception, of this email have on their systems or business. This 
email is not guaranteed to arrive in a timely manner.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message