Description
Is your feature request related to a problem? Please describe
Let's say I want to create a new plugin or library that depends on jackson-databind. In theory, I should be able to define a gradle file like this:
dependencies {
api "com.fasterxml.jackson.core:jackson-databind:${versions.jackson_databind}"
}
However, with OpenSearch, this will fail with a message like:
> Task :libs:opensearch-example-lib:thirdPartyAudit FAILED
Missing classes:
* com.fasterxml.jackson.annotation.JacksonAnnotationsInside
* com.fasterxml.jackson.annotation.JacksonInject
* com.fasterxml.jackson.annotation.JacksonInject$Value
...long list of missing classes...
That's because something in the build framework strips transitive dependencies and forces the library to manually find all transitive dependencies and include them. For this case it requires that I explicitly list two additional dependencies:
dependencies {
api "com.fasterxml.jackson.core:jackson-databind:${versions.jackson_databind}"
api "com.fasterxml.jackson.core:jackson-core:${versions.jackson_databind}"
api "com.fasterxml.jackson.core:jackson-annotation:${versions.jackson_databind}"
}
But for cases like the AWS SDK it becomes a bit absurd:
OpenSearch/plugins/repository-s3/build.gradle
Lines 49 to 92 in 1275017
This pain also compounds over time, as sometimes version updates result in a change in transitive dependencies, which cause the thirdPartyAudit check to fail.
Describe the solution you'd like
It would be great if we could leverage the build system to resolve transitive dependencies.
Why does OpenSearch do it this way? I assume it may have something to do with licensing, as this approach also requires that we include the license and notice file for all dependencies. Surely there's a better way to solve this problem?
Related component
Build