-
Notifications
You must be signed in to change notification settings - Fork 200
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
forced dependency resolution prevents dependencyUpdate lookup #194
Comments
Note that the following has no impact on dependencyUpdates:
|
Yep, this is a consequence of using Gradle's APIs for resolution. Some may want their configurations honored, while others don't. If we resolve the metadata manually we reinvent their infrastructure and don't gain improvements, but can fast track our own. I think detatched configurations are immune to this, but we encountered bugs there too. There isn't enough control over resolution strategies to tune this, so we probably can't do much directly. You can of course reduce the breadth of this, e.g. by not using
I think that is because it is forced only for the |
thanks for the ideas. Using gradle.taskGraph.hasTask(tasks.dependencyUpdates) will likely not work because the configurations closure is evaluated before the taskgraph construction, it seems
This however seems to work, and can be part of our workaround:
You can close this ticket btw, as wontfix. |
Unfortunately the only other option here is using a I guess the taskGraph trick worked in my testing when inside of a selection rule, e.g. configurations.all {
resolutionStrategy {
componentSelection {
all { selection ->
if (!gradle.taskGraph.hasTask(tasks.dependencyUpdates)) {
force "org.apache.commons:commons-lang3:3.5"
}
}
}
}
} But that is verbose and since no version is in your definition, it is resolved to Sorry that its an edge case without any great workaround. |
Hi,
With an empty gradle project and the build.gradle file below,
gradle dependencyUpdates
will not show that a new version of commons-lang3 is availlable. This might not be a bug, but just a consequence of the force option. Might still be good to have some solution.We did this because we wanted to use the same version of libraries across submodules of different types (gradle play framework plugin and java), and also for all transitive dependencies.
I could work on providing an example multi-module project with said 2 different kinds of modules to show our goal more clearly.
To reproduce (using gradle 4.3 myself):
The text was updated successfully, but these errors were encountered: