Gradle 找到本地依赖项，但未将其包含在编译类路径中

Question

I have my own, slightly patched version log4j-patched-1.2.17 of Apache Log4j. It is installed into my local Maven repository, can be found by Gradle, but is still not used for compilation.

My build.gradle of the consuming project:

plugins {
    id 'java'
}

repositories {
    mavenLocal()
}

dependencies {
    implementation 'de.mycompany.log4j:log4j-patched:1.2.17'
}

The POM (slightly abbreviated) of my log4j-patched is

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <!-- do_not_remove: published-with-gradle-metadata -->
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.mycompany.log4j</groupId>
  <artifactId>log4j-patched</artifactId>
  <version>1.2.17</version>
</project>

The test class I try to compile:

import org.apache.log4j.Logger;

public class TestClass {
    public static void main(String[] args) {
        System.out.println(Logger.class);
    }
}

The debug output of gradle clean build highly suggests Gradle does find log4j-patched-1.2.17 :

2022-05-27T15:45:43.160+0200 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Attempting to resolve component for de.mycompany.log4j:log4j-patched:1.2.17 using repositories [MavenLocal]
2022-05-27T15:45:43.160+0200 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.DefaultExternalResourceArtifactResolver] Loading file:/C:/Users/myuser/.m2/repository/de/mycompany/log4j/log4j-patched/1.2.17/log4j-patched-1.2.17.pom
2022-05-27T15:45:43.163+0200 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.DefaultExternalResourceArtifactResolver] Loading file:/C:/Users/myuser/.m2/repository/de/mycompany/log4j/log4j-patched/1.2.17/log4j-patched-1.2.17.jar
2022-05-27T15:45:43.163+0200 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver] Metadata file found for module 'de.mycompany.log4j:log4j-patched:1.2.17' in repository 'MavenLocal'.
2022-05-27T15:45:43.163+0200 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.DefaultExternalResourceArtifactResolver] Loading file:/C:/Users/myuser/.m2/repository/de/mycompany/log4j/log4j-patched/1.2.17/log4j-patched-1.2.17.module
2022-05-27T15:45:43.164+0200 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.PersistentModuleMetadataCache] Recording module descriptor in cache: de.mycompany.log4j:log4j-patched:1.2.17 [changing = false]
2022-05-27T15:45:43.164+0200 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Using de.mycompany.log4j:log4j-patched:1.2.17 from Maven repository 'MavenLocal'

However, the build aborts with

D:\path\to\project\src\main\java\TestClass.java:5: error: cannot find symbol
                System.out.println(Logger.class);
                                   ^
  symbol:   class Logger
  location: class TestClass

And also, the actual compile command misses the required jar as classpath element ( -classpath argument completely missing):

2022-05-27T15:51:16.777+0200 [DEBUG] [org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler] Compiler arguments: -source 1.8 -target 1.8 -d D:\Projekt\path\to\project\TestProject\build\classes\java\main -h D:\Projekt\path\to\project\TestProject\build\generated\sources\headers\java\main -g -sourcepath  -proc:none -s D:\Projekt\path\to\project\TestProject\build\generated\sources\annotationProcessor\java\main -XDuseUnsharedTable=true D:\Projekt\path\to\project\TestProject\src\main\java\TestClass.java

BUT: When I change the dependencies of my build.gradle to

dependencies {
    implementation files('c:/Users/myuser/.m2/repository/de/mycompany/log4j/log4j-patched/1.2.17/log4j-patched-1.2.17.jar')
}

The program compiles flawlessly.

Why does Gradle find log4j-patched.jar in my local repository, but still doesn't include it in the compile classpath?

EDIT: The output of gradle dependencies is

------------------------------------------------------------
Root project 'TestProject'
------------------------------------------------------------

[...]

compileClasspath - Compile classpath for source set 'main'.
\--- de.mycompany.log4j:log4j-patched:1.2.17

compileOnly - Compile only dependencies for source set 'main'. (n)
No dependencies

default - Configuration for default artifacts. (n)
No dependencies

implementation - Implementation only dependencies for source set 'main'. (n)
\--- de.mycompany.log4j:log4j-patched:1.2.17 (n)

runtimeClasspath - Runtime classpath of source set 'main'.
\--- de.mycompany.log4j:log4j-patched:1.2.17

[...]

(n) - Not resolved (configuration is not meant to be resolved)

A web-based, searchable dependency report is available by adding the --scan option.

BUILD SUCCESSFUL in 741ms
1 actionable task: 1 executed

Answer 1

The problem was caused by some faulty Gradle Module Metadata file ~/repository/de/mycompany/log4j/log4j-patched/1.2.17/log4j-patched-1.2.17.module . The way I had produced this artifact had somehow ommitted the "files" section inside that JSON file, which I now manually added:

"variants": [
  {
    "name": "apiElements",
    "attributes": {
      "org.gradle.category": "library",
      "org.gradle.dependency.bundling": "external",
      "org.gradle.jvm.version": 8,
      "org.gradle.libraryelements": "jar",
      "org.gradle.usage": "java-api"
    },
  "files": [          <-- was missing
      {
        "name": "log4j-patched-1.2.17.jar",
        "url": "log4j-patched-1.2.17.jar",
        "size": 486452,
        "sha512": "a3ef13253b028eb6c1f9b6c13d4cdabacd58248656e12ed452421cf6a11403d0677b731af14cd6c02acadaf6a476b5e6385cb3ea1103c0caab99bf7daf6ad123",
        "sha256": "cda50c4347907ce41d76a96fd6177af67f37d195cc72a83d35a077e887315fd2",
        "sha1": "5cb110f676d6cc7f1101a0a423a6f3574c222940",
        "md5": "9952949bf21e452ddd887025a6eb5aae"
       }
    ]
  },
  [..]
]

The lack of that "files" section could have been due to my (non-standard?) way of publishing this (already existing) jar.

If you don't care at all about Gradle Module Metadata files, you could also simply delete the corresponding files, respectively not produce it at all during publishing.

In my opinion, Gradle should give us more information during the build process on why a certain jar file cannot be found in the repository despite the artifact being installed correctly.