Closed suztomo closed 3 years ago
Spring-core artifact has optional dependency to reactor-core:
<dependency>
<groupId>io.projectreactor</groupId>
<artifactId>reactor-core</artifactId>
<version>3.2.8.RELEASE</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
Because reactor-core is not a direct dependency, the dependency was omitted.
Spring-core's NettyDataBufferFactory uses netty. Spring-core artifact has optional dependency to netty-buffer.
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-buffer</artifactId>
<version>4.1.34.Final</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
Because netty-buffer is not a direct dependency, the dependency was omitted.
Spring-core has optional dependency to Kotlin libraries:
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-reflect</artifactId>
<version>1.2.71</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-stdlib</artifactId>
<version>1.2.71</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
For example Intrinsics class is in kotlin-stdlib
$ jar tf /usr/local/google/home/suztomo/.m2/repository/org/jetbrains/kotlin/kotlin-stdlib/1.2.71/kotlin-stdlib-1.2.71.jar |grep internal/Intrinsics.class
kotlin/jvm/internal/Intrinsics.class
Spring-context's InstrumentationLoadTimeWeaver uses spring-instrument's org.springframework.instrument.InstrumentationSavingAgent
Spring-context has optional dependency to spring-instrument
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-instrument</artifactId>
<version>5.1.6.RELEASE</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
Spring-context's ConcurrentTaskExecutor uses ManagedExecutors via optional dependency.
<dependency>
<groupId>javax.enterprise.concurrent</groupId>
<artifactId>javax.enterprise.concurrent-api</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
The dependency is optional and thus not fetched.
Spring-context's GenericGroovyApplicationContext uses groovy package. Spring-context has optional dependency to groovy.
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy</artifactId>
<version>2.5.6</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
This is false positive because slf4j-api's MarkerFactory catches NoSuchMethodError and falls back to accessing the factory through field.
In this case, logback-classic:1.2.3
is the binding that does not have the methods. We may need to extend https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/402 to classes that check NoSuchMethodError.
This is the same issue as the unresolved https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/407. However with Mockito 2.25.1 the package name has changed a bit.
$ jar tf /usr/local/google/home/suztomo/.m2/repository/org/mockito/mockito-core/2.25.1/mockito-core-2.25.1.jar |grep MockMethodDis
org/mockito/internal/creation/bytebuddy/inject/MockMethodDispatcher.raw
This was true positive. com.google.http-client:google-http-client:1.28.0
was missing httpclient dependency. 1.29.0 has fixed it:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</dependency>
byte-buddy-agent:1.9.12 depends on junixsocket-native-common with scope:provided. A provided dependency of non-direct dependencies (in this case test scope) is omitted.
junixsocket is a Java/JNI library that allows the use of Unix Domain Sockets (AF_UNIX sockets) from Java. https://github.com/kohlschutter/junixsocket
<dependency>
<groupId>com.kohlschutter.junixsocket</groupId>
<artifactId>junixsocket-native-common</artifactId>
<version>${version.unixsocket}</version>
<scope>provided</scope>
</dependency>
These methods are available in AFUNIXSocket class in the artifact.
Logback-core has optional dependency to janino.
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
<scope>compile</scope>
<optional>true</optional>
</dependency>
Janino can not only compile a set of source files to a set of class files like JAVAC, but also compile a Java expression, block, class body or source file in memory, load the bytecode and execute it directly in the same JVM. http://janino-compiler.github.io/janino/
This package is part of org.codehaus.janino:commons-compiler:3.0.6
. org.codehaus.janino:janino:3.0.6
has dependency to it. They are in the same repository in Github.
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>commons-compiler</artifactId>
<version>${project.parent.version}</version>
</dependency>
This is the same issue I'm seeing with our transitive dependency upon commons-logging:commons-logging:1.2
. It declares optional dependencies upon log4j
, logkit
, and avalon-framework
.
@chingor13 Thank you for sharing observation. I'll update you once these issues are resolved.
@suztomo Is this a dupe of #1983?
Yes.
There are many false positives when the enforcer rule checks spring-cloud-gcp as below. This is because of the class path missing optional/provided libraries. A design doc is created to tackle this issue (http://go/jdd-supplemental-classpath)
Reproduce
With
<fail>true</fail>
at pom.xml,mvn verify
fails with many errors. Investigate the validity of them.