This message was deleted.

I no longer think this is true. According to build scans, both of these don't resolve any dependencies until execution time. This however

Configuration.incoming.artifactView {
  attributes.attribute(attributeKey, "jar")
}.artifacts.artifacts.map { it.file }

does resolve at least some files during configuration. The docs are really unclear on this

Hi, Tony. This is correct:

artifacts.artifactFiles

does NOT automatically perform resolution, it returns a

ResolutionBackedFileCollection

which will perform resolution only when its selected artifacts or dependencies are accessed. And

artifacts

just returns a

DefaultArtifactCollection

that contains a

ResolutionBackedFileCollection

, so it behaves in the same lazy manner because it is the same type doing the work. I agree the docs here aren't great. Where would you expect to find this information: in the Gradle documentation or inline as javadoc?

why not both? 😄 (but javadoc probably is most immediately useful, since I'll see it in the context of my IDE) The existing javadoc on

artifacts

is confusing. It just says something about how it's mainly for use as wiring as a task input, but what does that mean? What is it for? I care about the semantics of these APIs, because I'm trying to actually understand the whole system. Regarding documentation, in particular, I want to know which method calls result in dependency resolution and which do not. I think that should be called out explicitly everywhere

This is great feedback, thank you! I like the idea of methods being very clear in their javadoc about whether they will immediately perform resolution or not (most won't). I believe the note on

getArtifactFiles()

is trying to encourage you to use other methods like

getArtifacts()

- which provide other information in addition to the artifact files. It is indeed confusing that

getArtifacts()

suggests it is lazy and

getArtifactFiles()

does not. @Laura Kassovic - some feedback to consider here