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

Add possibility to exclude (transitive) dependencies #51

Open
sruehl opened this issue Feb 26, 2018 · 3 comments
Open

Add possibility to exclude (transitive) dependencies #51

sruehl opened this issue Feb 26, 2018 · 3 comments

Comments

@sruehl
Copy link

sruehl commented Feb 26, 2018

If this dependency is added:
dependency("com.openshift.jenkins", "openshift-pipeline", "1.0.54")
the integrationTests fail in a java.lang.StackOverflowError. This answer here indicates that this might be a problem of an unwanted dependency. We might need the ability to exclude dependencies from plugins.

@sruehl
Copy link
Author

sruehl commented Feb 26, 2018

For those who land here by a google search, here is a workaround:

// TODO: workaround for missing dependency exclude mechanism is pipeline plugin.
configurations.all {
    exclude("org.slf4j", "slf4j-log4j12")
    exclude("log4j", "log4j")
}

@mkobit
Copy link
Owner

mkobit commented Feb 26, 2018

I agree it should be more straightforward., and have better alignment with how Gradle users expect to exclude dependencies using https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html. I'd like the UX to feel more "Gradle native" by just using the existing dependencies idioms, but haven't quite figured out the right balance between DSL-friendly dependencies for Jenkins and using the built-in Gradle concepts

However, there should be a workaround for your use-case.

You can exclude the bad dependency from all configurations (if that is useful):

configurations {
  all { 
    exclude("org.slf4j", "slf4j-log4j12") 
    exclude("log4j", "log4j")
  }
}

Or exclude them specifically from the configurations created by the plugin or the integrationTest runtime. The configurations.all I think is better for now to not rely on the internal configuration changes while I try and figure out a better way to represent dependencies.

@mkobit
Copy link
Owner

mkobit commented Feb 26, 2018

Looks like you already figured out the workaround, thanks for posting it.

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

No branches or pull requests

2 participants