Narrow down transitive dependencies advice

[ArtyomGabeev]

Is your feature request related to a problem? Please describe. As I library owner, I would like to narrow down used transitive dependencies to fail only if there are ones required to be declared as 'api'.

onUsedTransitiveDependencies {
                severity('fail')
            }

Example output which should fail:

  These transitive dependencies should be declared directly:
    api 'com.fasterxml.jackson.core:jackson-annotations:2.18.4'
    api 'com.fasterxml.jackson.core:jackson-core:2.18.4'
    api 'com.fasterxml.jackson.core:jackson-databind:2.18.4'
    api 'jakarta.validation:jakarta.validation-api:3.0.2'
    implementation 'com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.18.4'
    implementation 'com.fasterxml.jackson.module:jackson-module-parameter-names:2.18.4'

Example which should not fail should not fail this check even though severity is fail:

  These transitive dependencies should be declared directly:
    implementation 'com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.18.4'
    implementation 'com.fasterxml.jackson.module:jackson-module-parameter-names:2.18.4'

It may be a symptom of different issue, I'm trying to address.

If I expose library with ABI which contains Message class from spring-messaging, and have next dependency configuration:

dependencyAnalysis {
  issues {
     onIncorrectConfiguration {
        severity('fail')
      }
      onUsedTransitiveDependencies {
         severity('ignore')
      }
  }
}

dependencies {
  implementation 'org.springframework:spring-jms'
}

Should the incorrect configuration check fail, and propose to rise spring-jms to api, which will trigger my attention? bcz spring-messaging is exposed and it's transitive dependency:

Shortest path from root project to org.springframework:spring-messaging:6.2.7 for compileClasspath:
:
\--- org.springframework:spring-jms:6.2.7
      \--- org.springframework:spring-messaging:6.2.7

Describe the solution you'd like Not sure how bad is idea to expose filter over advices. to end users. Otherwise in case of transitive dependency represented in ABI but not declared directly, closest parent dependency should be proposed to be upgraded due to incorrect configuration.

Describe alternatives you've considered Don't have any.

[autonomousapps]

Thanks for filing this request. I think that failing to declare an implementation dependency that is otherwise available transitively is a lesser issue than failing to do so for what should be an api dependency, from the perspective of users of your library.

However, failing to do so still sets up you, the library maintainer, for potential trouble in the future.

The way I have typically handled this kind of situation in my own projects is to use the bundle feature, available via dependencyAnalysis { structure { bundle(...) { ... } } }. I do this in cases where I consider dependencies tightly coupled, and do not wish to declare transitive dependencies that are implementation details.

[ArtyomGabeev]

Structured bundles will work, and I initially used them.

The issue actually with spring boot starters and their philosophy, add a spring-boot-security-starter, spring-boot-security will be added as well. So it means that for each start either a bundle needs to be created, or all dependencies from the starter needs to be applied.

I do not think it's an issue of this plugin, I can think of pre-building bundles programmatically for starter dependencies, but it violates and hides explicitness enforced by this plugin, which I personally like.

[ArtyomGabeev]

Other way around, can we make incorrectConfigurationIssue to always advice declaring dependency as api if it's part of ABI, even though if it's a part of structure bundle of starter dependency?

I'll provide a project example later this week. Thank you!

[autonomousapps]

One thing we could do is provide additional bundles out of the box for known use-cases, such as with Spring Boot. We already do this for Kotlin iirc.

[ArtyomGabeev]

Even if we provide it as part of the bundle, should we suggest adding a dependencies explicitly even though if they part of the structure bundle?

Here is an example: https://github.com/ArtyomGabeev/dep-analysis-test/blob/main/build.gradle#L40

I expect api 'org.springframework:spring-messaging:7.0.0-RC2' be adviced, even if it's part of spring-boot-starter-jms.

WDYT?

Thanks.