Log4j2: How to convince it that log4j-core.jar's classes are indeed present?

I am building a Java application into a single executable .jar file such that I unpack all required jar files that the application depends on and include all their contents together with the actual application's class files into a single .jar file (that's an IMHO very handy feature of the classic ant jar task. One then doesn't need to handle or distribute multiple jars nor nested .jars or such).

This approach worked all fine so far, but now I upgraded from log4j(v1) to log4j2 (I am actually using the slf4j-API but the log4j version underneath changed).

Since that upgrade my approach does not seem to work anymore but at runtime I keep getting an error message:
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console....

However, all the class files of the log4j-core-version.jar are included in my .jar file!
Apparently some piece of code tries to verify the presence of the original .jar file (and doesn't realize that the contained classes are indeed present and on the classpath) and then yells out.

I am using log4j-slf4j-impl-2.13.1.jar, slf4j-api-1.7.25.jar, log4j-api-2.13.1.jar and log4j-core-2.13.1.jar (or rather - as described - just their contents, not the actual .jars).

Is there a way to avoid that and tell the logging code to not bother re. the presence of that .jar? I would hate to have to deal with and always have to distribute two .jar files just because of this.

Jar files contain more than just classes. They can also contain resources. The Log4j 2 Plugin system uses a file to identify all the plugins in the jar and java.util.ServiceLoader uses a file to identify all the implementations of a service. Without these files stuff breaks.

Assuming you are using the Maven shade plugin you need to use the log4j shade transformer for plugins to be recognized and the ServicesResourceTransformer.

Right after sending off my question I suddenly had a suspicion: maybe the code that checks for the presence of log4j-core checks for something in the jar's MANIFEST-folder!?!
Originally I had always omitted the entire META-INF folder of the included .jars from being copied over into the generated new all-in-one.jar file. Now I only exclude the actual MANIFEST.MF file of those included .jars and - surprise, surprise - now the log4j code works and doesn't complain anymore. I didn't test exactly what file made the difference but apparently leaving those additional files in was the magic incantation (there is now a directory called "services" and another one called "versions" with several files each in the combined .jar as well as a bunch of pom files and a Log4j2Plugins.dat).