hiero-ledger / hiero-ledger/hiero-sdk-java

Re-evaluate scopes for third party dependencies

Open
#2,180 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.