Only locally available included builds are shown as unresolved

[Vampire]

I have build A with an included build build-logic that is a purely local included build without a published release.
The report show this as

Failed to determine the latest version for the following dependencies (use --info for details):
 - null:build-logic
The exception that is the cause of unresolved state: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find any matches for null:build-logic:+ as no versions of null:build-logic are available.
Searched in the following locations:
  - https://repo.maven.apache.org/maven2/null/build-logic/maven-metadata.xml
Required by:
    project :

If such a dependency that has no version available at all is coming from an included build, then it would be nice if it would not be shown as unresolved, but probably as up-to-date or not at all.

[ben-manes]

I would guess that we’d need to filter not just for ExternalDependency, but also exclude ExternalModuleDependency. Otherwise we think it is a BOM supplied version which is dynamically determined.

[Vampire]

Maybe you misunderstood me.
I was not talking about whether the declared dependeny has a version.
I meant when you tried to get the latest version using the + version and get no result at all.
Then, and if the dependency is served by an included build, it should be ignored as it is a purely local build organization dependency and not something published that could be updated.

[ben-manes]

I figured if we could simply not query for included build dependencies then that would solve the problem. We don't query for project dependencies and this is similar. My guess was that to detect if this is an included build we'd need to see if it was a ExternalModuleDependency, but I could be wrong. Otherwise we could probably ignore if the coordinate has a null value in either its group or artifactId properties. If you could provide a sample project then I can try to make a fix over the weekend.

[Vampire]

I don't know the Gradle internals there, but I guess it is not that trivial.
Usually those dependencies are external module dependencies that are substituted by the result of a project in an included build.
But it could of course be represented differently internally, I don't know.
null in the artifact is not possible I think.
And null in the group is not really meaningful, in my example it was null, but it could as well be set.

[Vampire]

You can use the branch foo of https://github.com/Vampire/setup-wsl to play with my concrete use-case.
But as I said, group being not set it not necessarily the case.
If you set a group for those included builds, the group should be set too.

[ben-manes]

Thanks! For context we get the dependency set like so. I’m guessing we can add another filter clause.

gradle-versions-plugin/gradle-versions-plugin/src/main/kotlin/com/github/benmanes/gradle/versions/updates/Resolver.kt

Lines 95 to 99 in ad0ce46

	val latest = configuration.allDependencies
	.filterIsInstance<ExternalDependency>()
	.mapTo(mutableListOf()) { dependency ->
	createQueryDependency(dependency as ModuleDependency)
	}

[Vampire]

The foo branch is gone, but you can use the normal master branch now.
You need to edit gradle/dependency-updates-report-aggregation/src/main/kotlin/net/kautler/dependency-updates-report-aggregation.gradle.kts and comment out the unresolved.dependencies.removeAll.

But just to be clear, that the group I filter there is null is specific to my build, it could as well be set to some value.

Actually I gave it a try to set the groups using the patch

diff --git a/gradle/build-logic/build-logic.gradle.kts b/gradle/build-logic/build-logic.gradle.kts
index 4233ac2..f18c9d0 100644
--- a/gradle/build-logic/build-logic.gradle.kts
+++ b/gradle/build-logic/build-logic.gradle.kts
@@ -30,7 +30,7 @@ dependencies {
     implementation(plugin(libs.plugins.grgit))
     implementation(plugin(libs.plugins.github))
     implementation(plugin(libs.plugins.kotlin.js))
-    implementation(":dependency-updates-report-aggregation")
+    implementation("net.kautler:dependency-updates-report-aggregation")
     implementation(libs.build.inject)
     implementation(libs.build.github.api)
     implementation(libs.build.snakeyaml)
diff --git a/gradle/build-logic/gradle.properties b/gradle/build-logic/gradle.properties
index f5c5b07..5d7bcc7 100644
--- a/gradle/build-logic/gradle.properties
+++ b/gradle/build-logic/gradle.properties
@@ -12,6 +12,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

+group = net.kautler
 org.gradle.caching = true

 dependency.analysis.print.build.health = true
diff --git a/gradle/dependency-updates-report-aggregation/gradle.properties b/gradle/dependency-updates-report-aggregation/gradle.properties
index f5c5b07..5d7bcc7 100644
--- a/gradle/dependency-updates-report-aggregation/gradle.properties
+++ b/gradle/dependency-updates-report-aggregation/gradle.properties
@@ -12,6 +12,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

+group = net.kautler
 org.gradle.caching = true

 dependency.analysis.print.build.health = true
diff --git a/gradle/dependency-updates-report-aggregation/src/main/kotlin/net/kautler/dependency-updates-report-aggregation.gradle.kts b/gradle/dependency-updates-report-aggregation/src/main/kotlin/net/kautler/dependency-updates-report-aggregation.gradle.kts
index e1df0b0..c109937 100644
--- a/gradle/dependency-updates-report-aggregation/src/main/kotlin/net/kautler/dependency-updates-report-aggregation.gradle.kts
+++ b/gradle/dependency-updates-report-aggregation/src/main/kotlin/net/kautler/dependency-updates-report-aggregation.gradle.kts
@@ -79,7 +79,7 @@ if (gradle.parent == null && parent == null) {
     dependencies {
         includedBuildNames
             .filterNot { it == "conditional-refresh-versions" }
-            .forEach { dependencyUpdatesResults(":$it") }
+            .forEach { dependencyUpdatesResults("net.kautler:$it") }
     }

     tasks.dependencyUpdates {

But with that the dependencies are not shown as unresolved, but as up-to-date.
So it maybe is more that you somewhere set the group to the string value "null" instead of null.

[Vampire]

Yep, my suspicion was correct.
Will send a PR soon that fixes it.
With that it will not fail on unresolved but instead treat them as hidden.

[ben-manes]

Released in v46