From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

somewhat related question to the above. For years now, I've known it to be Evil :tm: to resolve dependencies during configuration. However, I only recently noticed this in a build scan. This differentiates between user- and gradle-initiated resolution. Is the latter "ok"? Or am I doing it wrong? Code snippet in thread

```val artifacts = configurations
  .getByName("compileClasspath")
  .artifactsFor("jar")
tasks.register&lt;ResolveDependenciesTask&gt;("resolveDependencies") {
  setCompileClasspath(artifacts)
}```
where `artifactsFor()` is defined as:
```private fun Configuration.artifactsFor(attrValue: String): ArtifactCollection = incoming
  .artifactViewFor(attrValue)
  .artifacts

private fun ResolvableDependencies.artifactViewFor(attrValue: String): ArtifactView = artifactView {
  it.attributes.attribute(attributeKey, attrValue)
  it.lenient(true)
  it.componentFilter { componentIdentifier -&gt;
    componentIdentifier is ModuleComponentIdentifier
  }
}```
note this is necessary because I'm dealing with an Android project

simply configuring that task resolves dependencies (by gradle)

I suppose this is because you're calling `.artifacts` on your artifact view at configuration time. How about doing that in a provider you pass to `setCompileClasspath` instead? (such that it's only resolved at execution time)

If I use `provider { artifactView.artifacts.artifactFiles }`, I still see this, which does look like it's resolving the dependencies at configuration time. What am I missing?

no matter what I try, it really wants to resolve these dependencies during configuration :disappointed: