Note that if your /etc/hosts file does not include an entry for your computer’s hostname, then many unit tests may execute slow due to DNS lookups to translate your hostname to an IP address in InetAddress.getLocalHost(). To remedy this, you can execute the following:

You can run tests using the target JRE (i.e., JRE 8) as follows:

1. Maven Toolchains is used to employ additional JDKs required for tests. You either need to have a user-level configuration in ~/.m2/toolchains.xml or explicitly provide one to the Maven: ./mvnw --global-toolchains /path/to/toolchains.xml.

   An example toolchains.xml containing a JDK 8 toolchain

   <?xml version="1.0" encoding="UTF8"?>
   <toolchains>
     <toolchain>
       <type>jdk</type>
       <provides>
         <version>1.8.0_372</version>
       </provides>
       <configuration>
         <jdkHome>/usr/lib/jvm/java-8-openjdk-amd64</jdkHome>
       </configuration>
     </toolchain>
   </toolchains>

2. Run Maven tests with the java8-tests profile:

   ./mvnw verify -Pjava8-tests,!java8-incompat-fixes

Certain tests use Docker to spawn necessary external services. Docker tests are configured using the docker Maven profile, which is activated by default for the CI environment. You can locally enable this profile by passing a -P docker argument to your ./mvnw commands.

You can connect your IDE to a ./mvnw test run by

1. Run ./mvnw test -pl :log4j-core-test -Dtest=FooBarTest -Dmaven.surefire.debug

2. Use "Run > Attach to process" in IntelliJ IDEA

There are certain Maven profiles activated only for CI. As a consequence of this, you can observe certain CI failures that you can’t reproduce locally. To work around this, you can activate CI profiles by running Maven commands as follows:

Try removing all "Override compiler parameters per-module" entries in "Settings > Build, Execution, Deployment > Compiler > Java Compiler".

Log4j uses the BND Baseline Maven Plugin to enforce its semantic versioning policy. Following the OSGi versioning best practices, both Log4j artifacts and packages are versioned. If you modify Log4j’s public API, a BND Baseline error like the following will occur:

The solution of the error depends on the change kind (Delta):

MICRO

For patch level changes modify the package-info.java file of the org.apache.logging.foo.bar package and update the @Version annotation to the number suggested by BND: increment just the patch number.

@Version("2.3.5")
package org.apache.logging.foo.bar;

MINOR

Changes of type MINOR require more work:

• Make sure that the current Log4j version is a minor upgrade over the last released version. If that is not the case (e.g., it is 2.34.5-SNAPSHOT) modify the <revision> property in the main POM file (e.g., change it to 2.35.0-SNAPSHOT).

• Make sure to add a changelog entry of type added, changed or deprecated to your PR.

• As in the MICRO case modify the package-info.java file of the package and update the @Version annotation to the next Log4j version (2.35.0 in the example) and not the minimal version number suggested by BND. The purpose of this policy is to have an alignment between package versions and the last Log4j version, where an API change occurred.

MAJOR

Changes of type MAJOR (i.e. breaking changes) are not accepted in the 2.x branch. If you believe it is not a breaking change (e.g., you removed a class documented as private), the development team will guide you on how to solve it.