hiero-ledger / hiero-ledger/hiero-sdk-java
Re-evaluate scopes for third party dependencies
- Dominant language
- Java
- Stars
- 264
- Forks
- 192
- Avg merge
- 2d
- Merged PRs (30d)
- 39
Description
## Background
This is about whether some third party dependencies that are currently defined in scope `requires` (**not** re-exported at compile time) should be moved to scope `requires transitive` (re-exported at compile time).
## Status
Concretely, it is about the following dependencies defined in [module-info.java](https://github.com/hashgraph/hedera-sdk-java/blob/main/sdk/src/main/java/module-info.java).
```
requires com.esaulpaugh.headlong;
requires com.google.common;
requires io.grpc.stub;
requires io.grpc;
requires org.bouncycastle.provider;
requires org.slf4j;
```
All of these libraries contain Types – public Interfaces or Classes – that are exposed in a `public` method of our code. Hence, users of the SDK potentially need them (at compile time) to call a certain part of our code.
This situation was discovered when we started using the [dependency scope check](https://github.com/autonomousapps/dependency-analysis-gradle-plugin/) in the new Gradle setup. The check failed, telling the scope should be changes to `requires transitive` for the libraries listed above.
In order to make the check pass, we added the [following exclusions](https://github.com/hashgraph/hedera-sdk-java/blob/d632f6aeaee9d50f3e18d054fad9b59d4f7793ea/sdk/build.gradle.kts#L65-L78):
```
dependencyAnalysis.abi {
exclusions {
// Exposes: org.slf4j.Logger
excludeClasses("logger")
// Exposes: com.google.common.base.MoreObjects.ToStringHelper
excludeClasses(".*\\.CustomFee")
// Exposes: com.esaulpaugh.headlong.abi.Tuple
excludeClasses(".*\\.ContractFunctionResult")
// Exposes: org.bouncycastle.crypto.params.KeyParameter
excludeClasses(".*\\.PrivateKey.*")
// Exposes: io.grpc.stub.AbstractFutureStub (and others)
excludeClasses(".*Grpc")
}
}
```
## What to do
Check each of the dependencies and do one of three things:
1. Change our public API such that it uses no types from the dependency. Maybe it's just one or two types that were used by mistake before the scope check existed.
2. Keep the necessary exclusions. Maybe it was not intended to use the type(s) on the API, or the place where the types are used is not considered public API despite the fact that it is technically accessible. Maybe change the API at a later point.
3. Move the dependency scope to `requires transitive` as a conscious decision to make the 3rd party dependency part of our API.
Contributor guide
Assessment
This issue has not been assessed yet.