The configuration was resolved without accessing the project in a safe manner

Help/Discuss
1

Noticed that when trying to migrate to Gradle 5, I get the warning:
The configuration was resolved without accessing the project in a safe manner.

I’m trying to get some more information about how to resolve this. In my case I have a multi-project build using the Java and Distribution plugins.

In my case, the root project is doing two things, configuring subprojects and defining a set of distributions. My distribution is roughly defined in this way, which I suspect is somehow the issue:

distributions {
  main {
    contents {
      with generateDistCopySpec()
    }
  }
}

def generateDistCopySpec() {
  copySpec {
    apps.collect { with appCopySpec(it, ...) }
}

def appCopySpec(Project app, ...) {
    into(distPath) {
        from app.tasks.withType(Jar) // app artifact
        from app.configurations.runtimeClasspath - app.configurations.providedCompile
     }
}
2

This style is a bit wierd to me where you are using methods that aren’t guaranteed to be in scope. I’m surprised it compiles to be fair. I’d do this instead

distributions {
  main {
    contents {
      with generateDistCopySpec(project, apps)
    }
  }
}

def generateDistCopySpec(Project project, apps) {
  project.copySpec {
    apps.collect { with appCopySpec(it, ...) }
}

There’s the same weirdness in appCopySpec where “into” is not guaranteed to be in scope (eg if you invoked the method outside of copySpec {...}). I’m guessing gradle will complain about that next

3

Yeah, sorry the missing copySpec {} in def appCopySpec was a typo. Tried to shorten what we really have. Seems to work either way with your suggestions or without, but the warning about unsafe access is still there.

The configuration :parent-project:app-project:runtimeClasspath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a thread not managed by Gradle or from a different project. See https://docs.gradle.org/5.1/userguide/troubleshooting_dependency_resolution.html#configuration_resolution_constraints for more details. This behaviour has been deprecated and is scheduled to be removed in Gradle 6.0.

What i’ve noticed is, that creating this copySpec from the subproject’s build.gradle doesnt seem to emit this warning, it’s only when its done in in the root project’s build script.

The fix I’ve found to this warning is to create a distribution for each subproject, and in the root project’s build script to use from <subproject>.distributions.main.contents instead of from <subproject>.configurations.runtimeClasspath

Any idea if this is the “correct” way to do things, or is there something else I’m missing. My original goal was to avoid duplicating jars by having subproject distributions, but if this is safer/faster I’m OK with that.

4

Update: The solution above seems to have quieted the warning for the distribution plugin tasks (and not ospackage tasks) in my case.

However, putting together a trivial build env to reproduce the warnings triggered by the ospackage plugin, I’m finding that I still see this warning even without the ospackage plugin.

Repro repo available here: https://github.com/kunickiaj/rpm-warn-repro
Any suggestions as to the correct solution to accomplish this would be greatly appreciated.