Hi, Gradle folks! Can someone share wisdom about migration from

Configuration.getResolvedConfiguration()

to

Configuration.getIncoming()

? I've found an observable behaviour change, even though it's a bit small: if one adds file dependencies (like

implementation(files("libs/a.jar"))

): • Old API wouldn't return them from

ResolvedConfiguration.getResolvedArtifacts()

but would return them in

ResolvedConfiguration.getFiles()

, • But new one will return both from

ResolvableConfiguration.getArtifacts()

, but for standalone files their

ResolvedArtifactResult.getId()

would be (at 8.12 at least) of

org.gradle.internal.component.local.model.OpaqueComponentArtifactIdentifier

, and the only things accessible without using the internal class are `toString`/`displayName` and friends, and they aren't fully informative, for me they only contain file name. On older API I've run through

ResolvedConfiguration.getFiles()

and for all files not found in

.getResolvedArtifacts()

I'd mark them down for my usage by their path, but in new API those are in artifacts, and the component name lacks full path.

Is the part with

implementation(files("libs/a.jar"))

under your control? Because

files

and

fileTree

for dependencies is almost always a bad idea and code smell. If you really need to use local files as dependencies, you should usually at least use a

flatdir

repository instead, that mitigates at least some of the quirks the others have.

Yeah, ofc they are. I'm asking that from resolution side of question: I'm actually updating a plugin of mine that validates resolution results and if it doesn't like something it reports which part exactly it didn't like. For standalone files (that should be discouraged) it reported them as standalone file/dir at $path. For module dependencies it just reports from which module it came, it's enough to act on it.

Ok, so in that regard / from that PoV it is "not" under your control but more like you write a plugin that someone else could use and could have such a dependency. 😞

I don't see how this method would help, I'm really only interested in resolved dependencies.It just so happens that the rare and discouraged case of local file dependencies under updated API would be just a bit misrepresented for my needs. I could just say it's not a bug and go along, but maybe something deeper is going on with the design?

Why are you interested in resolved dependencies in that case? Such dependencies do not come in transitively, but directly from the project. So if you check in

withDependencies

whether such a dependency is declared, it should be sufficient, shouldn't it?

No, I actually need to check the contents of final classpath, not just list of files/modules.

Why? For those file-dependencies

The main thing I'm doing is inspecting classpath for duplicates/intersections between dependencies.While I don't care much about file dependencies, when I've written the original version it would try to report, if it found something, where it was actually found. For module dependencies the name of it (g a v) is absolutely fine. In case is is not I've written it in a way that it would say "it's not a module dependency, here is a path to it".