logging-log4j2 | Apache Log4j 2 is a versatile

Until recently, the build process of log4j-core depends on the build process of a companion log4j-core-java9 module.

This multi-module build approach was introduced in this issue and the changes performed are described in this commit.

In a future version of the library these dependencies will be removed as described in this issue precisely to avoid potential dependency problems. The issue provides more information about was it going on:

Log4j API and Log4j Core have to build the Java 9 classes in one Maven module and then copy them into the "normal" module. The Java 9 projects are not deployed during a release. The pom.xml files were specifying both as provided dependencies. When the enforcer plugin sees this it is trying to resolve them - sometimes - and fails. It seems these don't need to be declared as dependencies because they are configured into the dependency plugin. So the dependencies should be removed from the pom files.

If you need to build the code from an older version from source, according to the changes introduced in the aforementioned commit, you first need to assembly log4j-core-java9 and then use the dependency in the build process of log4j-core itself.

In a nutshell, try the following.

First, log4j2 uses toolchains in its build process, so for JDK 11 you may need to provide an entry in ~/.m2/toolchains.xml file like the following:

Thanks to @rgoers, turns out I was missing the @Named annotation on the parameters.

So my MyLoggerTest works with the following:

Yes. The Rollover strategy uses FileExtension to automatically add a CompressAction based on the file extension, but you can do this yourself just by configuring a custom Action. While you can look at ZipoCompressAction as a template for how to implement the action, you would also need to look at DeleteAction to see how to declare your custom action as a plugin.

Solution: the regex seems to have been wrong, removing the spaces around 'startup' makes it work.