Maven custom properties precedence

If you’ve worked with Maven before, you are probably aware that it allows you to define custom properties that can then be used throughout your build as placeholders (for value re-use or configuration purposes) or even as a mean of configuring your final build resources using filters. These come very handy for defining environment-specific configurations.

These custom properties can be defined at multiple locations. But what happens when you define (or re-define) the same property in multiple locations? Which location will have precedence on others? Amazingly, even if Maven is very popular in the Java ecosystem, I could not find any useful reference on this.

After research and thorough testing, I’ve come up with this order of precedence which Maven uses when resolving custom properties:

  1. System properties: set with -Dxyz=value on the command line.
  2. From currently active profile(s): settings.xml in user home directory first, then profiles.xml in project root directory, then in profiles defined in your pom.xml.If many profiles are active, and a property is defined in more than one of those, the order of precedence is based on the last profile in which this property is defined, in alphabetical order of profile name.
  3. In the properties section of your pom.xml.
  4. Lastly, in properties defined in filters. If a property is defined in multiple filters, then the last one (in order of appearance in your filters section) has precedence over the others.

Good to know!!This came handy recently for me so I share it here, hoping it will help someone else!


The leader and “his team”

People seem to have a hard time treating a group of individuals working on a common goal as a Team. I’ve observed that many people will naturally expect commitment and liability from leaders, even unofficially appointed leaders, or natural leaders, instead of teams.

But why is that so? Why are people seeing hierarchy in leadership?

The answer might come from us being deeply entangled in our Fayolism roots. For most of the 19th and 20th centuries, management styles have always focused on creating a hierarchy of command and control. This has worked great in traditional, repetitive and manual work environments (which were prevalent up to a few decades ago), and this management style still sneaks in our daily lives as software professionals. Even with the best intentions to get away from these management styles, most people still experience a few behaviours reminiscent of these roots. The leader leads the team, thus is responsible for “his team”. It looks like it is comforting to know that a single neck can be wrung if something happens.

It won’t be a surprise to anyone that writing software is certainly not repetitive (most of it at least, if it is for you, you should definitely consider giving your current job a good thought). A more collaborative, egalitarian work environment is often more appropriate, and has proven much healthier in many situations.

To help cultivate a more collaborative environment around me, I’ve come up with a few rules of thumbs that I try to honour continually as a team-focused leader:

  • Never, never commit on work on behalf of the team
  • Systematically use “My team and I” or “We” formulations when communicating those team commitments or decisions
  • Always estimate and plan in teams

Creating a team-focused mindset in daily communications with the different stakeholders will slowly but surely help in removing this wringable-leader delusion.