Activating a default Maven profile defined in settings.xml with other profiles in the pom.xml


In Apache Maven, there are different places to configure profiles:

  • The project pom.xml
  • The user’s settings.xml
  • The installations settings.xml

I wanted every developer to be able to customise the build properties independently of the pom.xml. It is a very bad practice to have everyone modifying the pom.xml locally. One would also argue that it is a very bad practice to have developers customise build properties. That’s a debate for another time 🙂

The profiles that we have are:

  • Development (default)
  • Jenkins (continuous integration)
  • Test
  • Acceptance
  • Production

The profiles define the target environment for the build.

At first, I tried to define a profile as activeByDefault in the settings.xml file while setting the other profiles in the pom.xml not active by default. That did not work at all because in this case the profile defined in the settings.xml is active at any time and overrides other profiles.

The solution that I found was to use a property to activate a profile. The profile defined in the settings.xml is the Development profile. It would be activated by the absence of such a property. Indeed, it would be boring to have to specify a property for most of the builds.

The settings.xml looks like this:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
	  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
			      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <profiles>
    <profile>
      <id>Development</id>
      <activation>
	<property>
	  <name>!env</name><!-- The exclamation mark indicates that the property shall be absent -->
	</property>
      </activation>
      <properties>
	<target.environment>Development</target.environment>
	...
      </properties>
    </profile>
  </profiles>
</settings>

When using the Maven command mvn help:active-profiles, it yields:

The following profiles are active:

 - Development (source: settings.xml)

The development profile is active if the property env is not set using the Maven command line parameter -Denv=xxx.

All the other profiles are defined in the pom.xml:

...
  <profiles>
    <profile>
      <id>Jenkins</id>
      <activation>
	<property>
	  <name>env</name>
	  <value>Jenkins</value> <!-- This is the value for that property that will activate the profile -->
	</property>
      </activation>
      <properties>
	<target.environment>ContinuousIntegration</target.environment>
	...
      </properties>
    </profile>
    <profile>
      <id>Test</id>
      <activation>
	<property>
	  <name>env</name>
	  <value>Test</value>
	</property>
      </activation>
      <properties>
	<target.environment>Test</target.environment>
	...
      </properties>
    </profile>
    <profile>
      <id>Acceptance</id>
      <activation>
	<property>
	  <name>env</name>
	  <value>Acceptance</value>
	</property>
      </activation>
      <properties>
	<target.environment>Acceptance</target.environment>
	...
      </properties>
    </profile>
    <profile>
      <id>Production</id>
      <activation>
	<property>
	  <name>env</name>
	  <value>Jenkins</value>
	</property>
      </activation>
      <properties>
	<target.environment>Production</target.environment>
	...
      </properties>
    </profile>
...

To activate any profile from the pom.xml instead of the Development profile, we just have to pass the env property to the command line. For example:

$ mvn -Denv=Test help:active-profiles

The command above yields the following result:

The following profiles are active:

 - Test (source: pom)

Considerations on configuring my GitHub account on a new Ubuntu install


I changed laptops and I needed to reconfigure my GitHub account.

At first, I wanted to reuse the SSH key that I used on my other computer, which works fine. Afterwards, I changed my mind as it is actually less hassle to generate a new key and to add it to my GitHub account. Once the new laptop was configured, I could remove the former key.

In any case, I first needed to install an SSH client in order to follow the setup guide from GitHub. I installed OpenSSH with the following command:

$ sudo apt-get install openssh-client

Then I could follow the procedure to generate a new key pair and configure my account.

If I had wanted to reuse my existing key and passphrase, I could have copied the following two files from my current computer to the ~/.ssh folder of the target computer.

  • ~/.ssh/id_rsa
  • ~/.ssh/id_rsa_pub
%d bloggers like this: