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

forced dependency resolution prevents dependencyUpdate lookup #194

Closed
tkruse opened this issue Nov 8, 2017 · 4 comments
Closed

forced dependency resolution prevents dependencyUpdate lookup #194

tkruse opened this issue Nov 8, 2017 · 4 comments

Comments

@tkruse
Copy link
Contributor

tkruse commented Nov 8, 2017

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):

buildscript {
    repositories {
        jcenter()
    }
}

plugins {
    // use with gradle dependencyUpdates, to check for updates
    id "com.github.ben-manes.versions" version "0.15.0"
}

apply plugin: 'java'

repositories {
    jcenter()
}

configurations.all {
    resolutionStrategy {
        force(
                "org.apache.commons:commons-lang3:3.5",
        )
    }
}

dependencies {
    compile("org.apache.commons:commons-lang3")
}
@tkruse
Copy link
Contributor Author

tkruse commented Nov 8, 2017

Note that the following has no impact on dependencyUpdates:

dependencies {
  compile("org.apache.commons:commons-lang3:3.5") {force = true}
}

@ben-manes
Copy link
Owner

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 all. Or you could observe the task graph and not apply some rules, e.g. !gradle.taskGraph.hasTask(tasks.dependencyUpdates).

compile("org.apache.commons:commons-lang3:3.5") {force = true}

I think that is because it is forced only for the compile configuration, but not all others. Since we copy the configuration and rewrite the dependencies to a dynamic query, it must lose the force on the update check. But, if you want to force other configurations then the above probably won't apply as globally as your original.

@tkruse
Copy link
Contributor Author

tkruse commented Nov 8, 2017

thanks for the ideas.
Not sure which configurations I could use instead of all. Using "compile" reproduces the problem, using something else I am not sure what will end up in my classpath. Note this also indicates that {force = true} works differently or at a different time.

Using gradle.taskGraph.hasTask(tasks.dependencyUpdates) will likely not work because the configurations closure is evaluated before the taskgraph construction, it seems

A problem occurred ...
> Task information is not available, as this task execution graph has not been populated.

This however seems to work, and can be part of our workaround:

if (!gradle.startParameter.taskNames.contains('dependencyUpdates')) {

You can close this ticket btw, as wontfix.

@ben-manes
Copy link
Owner

Unfortunately the only other option here is using a componentSelection rule to reject the candidate. When using --info it appears that force makes the metadata appear as the version, so it is very forceful in ensuring the version.

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 none.

Sorry that its an edge case without any great workaround.

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