Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transitive platform dependencies may prevent exclusions from being applied #310

Closed
akvone opened this issue Sep 19, 2021 · 3 comments
Closed
Milestone

Comments

@akvone
Copy link

akvone commented Sep 19, 2021

We have a project with spring-boot-dependencies:2.4 and excluded transitive dependency (junit):

dependencies {
    implementation('org.apache.xmlrpc:xmlrpc-client')
    implementation('com.fasterxml.jackson.core:jackson-databind')
}

dependencyManagement {
    imports{
        mavenBom("org.springframework.boot:spring-boot-dependencies:2.4.4")
    }
    dependencies {
        dependency('org.apache.xmlrpc:xmlrpc-client:3.1.3') {
            exclude 'junit:junit'
        }
    }
}

When we tried to bump a version to spring-boot-dependencies:2.5 the junit appeared again.
It turned out that spring-boot-dependencies:2.5 brings jackson dependencies with version 2.12 instead of 2.11 which in turn started to publish Gradle metadata which brings Jackson platform (jackson-bom). The platform controls junit and this disables our exclusion.

The same behavior appears if we just use jackson dependency with version 2.12 or if we use jackson-bom platform.

After reading the Gradle documentation and some existing issues we found a solution: we also exclude junit from the platform:

dependencyManagement {
    imports{
        mavenBom("org.springframework.boot:spring-boot-dependencies:2.5.4")
    }
    dependencies {
        dependency('org.apache.xmlrpc:xmlrpc-client:3.1.3') {
            exclude 'junit:junit'
        }
        dependency('com.fasterxml.jackson:jackson-bom:2.12.4'){
            exclude 'junit:junit'
        }
    }
}

The question is: Do we use the correct way to handle such logic? And could the documentation contain a warning about this case?

@akvone
Copy link
Author

akvone commented Sep 19, 2021

We use gradle dependencies --configuration=runtimeClasspath to see the classpath

@wilkinsona
Copy link
Contributor

wilkinsona commented Sep 20, 2021

I am surprised that JUnit appearing in Jackson's bom (which should only affect its version if it already appears in the dependency graph) prevented its exclusion. It would appear that the appearance of the dependency constraints in the resolution result is confusing the algorithm that determines the dependencies that should be excluded. I think it probably needs to be updated to ignore dependencies where the selected variant's org.gradle.category attribute has a value of platform.

In the meantime, your workaround is a good temporary solution.

@akvone
Copy link
Author

akvone commented Sep 22, 2021

Got it, thank you.

@wilkinsona wilkinsona changed the title Platform usage disables dependency management exclusions Transitive platform dependencies may prevent exclusions from being applied May 10, 2023
@wilkinsona wilkinsona added this to the 1.1.1 milestone May 10, 2023
wilkinsona added a commit that referenced this issue Jul 13, 2023
In 3d05983, the fix for gh-310, an attempt was made to prevent
dependencies in a transitive platform dependency from stoping
exclusions from being applied correctly. Unfortunately, it went
to far which led to a dependency's parent pom being excluded. This
could cause resolution failures if that parent contained
dependency management that was required for the child's dependencies
to resolve correctly.

This commit reworks that changes so that the platform dependency
itself is added to the included nodes but to then stop processing.
This prevents the platform dependency itself from being excluded but
ensures that any of its dependencies due not influence the
application of exclusions.

Fixes gh-360
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants