[blindpirate]

Unblocks the milestone-30 publish Mikhail Lopatkin is waiting on.

Failing build: https://builds.gradle.org/buildConfiguration/GradleNative_NativePlatform_Publishing_PublishJavaApiAlpha/117007595

groovy.lang.MissingPropertyException: Could not get unknown property 'archivesBaseName' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

Root cause

Project.archivesBaseName was removed in Gradle 9, and this build is on 9.4.1.

The Gradle 9 migration (dfe6952, "Migrate to gradle 9") converted the setter usages in test-app/build.gradle:

-applicationName = 'native-platform-test'
-archivesBaseName = 'native-platform-test'
+application { applicationName = 'native-platform-test' }
+base { archivesName = 'native-platform-test' }

…but missed the remaining reader at test-app/build.gradle:25. The error surfaces against DefaultDependencyHandler because that's the innermost delegate in the enclosing dependencies {} closure.

Blast radius

Worth being precise about this, because the failing line lives in test-app but that is not where the build actually breaks.

PublishJavaApiAlpha itself only reported Snapshot dependencies failed: 5. The real failures were in all eight per-platform Alpha jobs, in the :native-platform:uploadJni / :native-platform:uploadNcursesJni steps — e.g. 117007587, whose build problem is the identical archivesBaseName exception.

That's expected: test-app/build.gradle is evaluated during the configuration phase regardless of which project's task you invoke, so a broken line in it fails every task in the build. The one-line fix therefore unblocks the entire publish matrix, not just :test-app:uploadMain.

Why only publishing jobs hit it

The block is guarded by versions.useRepo, and gradlebuild.VersionDetails.isUseRepo() is true only for the Snapshot/Alpha/Milestone/Release build types. Ordinary dev and CI test builds never configure it, which is why this went unnoticed since December.

The fix

Read the value from the base extension, which is already configured at line 12 of the same file:

download "$group:${base.archivesName.get()}:${version}"

PublishPlugin.getArchivesBaseName(Project) in buildSrc does the same thing via BasePluginExtension.getArchivesName(); using the extension directly from the Groovy DSL is equivalent and avoids pulling a buildSrc import into the script.

Verification

Reproduced locally before the fix (a dummy publishToken is needed to get past ReleasePlugin's configuration-time credential check and reach :test-app):

$ ./gradlew :test-app:help -Psnapshot -PpublishToken=dummy
* Where: Build file 'test-app/build.gradle' line: 25
* What went wrong: Could not get unknown property 'archivesBaseName' ...

After the fix, both the snapshot and the alpha/milestone path configure cleanly, and the dependency resolves to the intended coordinates:

$ ./gradlew :test-app:help -Psnapshot -PpublishToken=dummy
BUILD SUCCESSFUL

$ ./gradlew :test-app:dependencies --configuration download -Palpha=milestone-30 -PpublishToken=dummy
download
\--- net.rubygrapefruit:native-platform-test:0.22-milestone-30 FAILED
BUILD SUCCESSFUL

(The FAILED marker is just the artifact not being published yet — the point is that the coordinates are now built correctly. Configuration-time success is what was broken.)

A plain ./gradlew :test-app:help dev build is unaffected, as the changed line sits inside the useRepo guard.

CI verification on this branch:

PublishJavaApiSnapshot #189 — SUCCESS, all 17 builds in the dependency graph green on bdc12fc9, published 0.22-snapshot-20260906135345+0000.

I used the Snapshot job rather than Alpha/Milestone deliberately: it exercises the identical versions.useRepo code path (isUseRepo() is true for both) and runs the same :native-platform:uploadJni and :test-app:uploadMain steps, but publishes a disposable timestamped snapshot to libs-snapshots-local instead of writing to libs-releases-local. In particular it avoids consuming the milestone-30 coordinate from an unmerged branch.

The eight per-platform uploadJni publishes — the exact jobs that failed on master — all passed:

Job	Result
PublishMacOsAarch64Snapshot	✅
PublishMacOsAmd64Snapshot	✅
PublishLinuxAmd64Snapshot	✅
PublishLinuxAarch64Snapshot	✅
PublishLinuxAmd64Ncurses6Snapshot	✅
PublishLinuxAarch64Ncurses5Snapshot	✅
PublishWindowsAmd64Snapshot	✅
PublishFreeBsdAmd64Snapshot	✅

Scope

I grepped the repo for other Gradle-9-removed APIs that would only be exercised on the versions.useRepo / publishing path — archivesBaseName, libsDir, distsDir, mainClassName, uploadArchives, getConvention(), archiveName/destinationDir/classesDir, project.buildDir, and the removed compile/runtime/testCompile configurations. This line was the only hit; versions.useRepo itself appears nowhere else. No other changes needed.

One caveat on that sweep: this bug's signature is dynamic Groovy property resolution, which static grepping cannot fully rule out — it only fails at configuration time, on a code path that no dev or CI build exercises. The durable guard would be a cheap CI job running a configuration-only task with -Psnapshot, which would have caught this in December. Out of scope here, but worth considering separately.

[blindpirate]

Verified on CI: Publish Native Platform Snapshot #189 — SUCCESS on bdc12fc9, published 0.22-snapshot-20260906135345+0000. All 17 builds in the dependency graph are green.

I ran the Snapshot job rather than Alpha/Milestone on purpose: it exercises the identical versions.useRepo code path (VersionDetails.isUseRepo() is true for both) and runs the same :native-platform:uploadJni and :test-app:uploadMain steps, but publishes a disposable timestamped snapshot to libs-snapshots-local instead of writing to libs-releases-local — so it doesn't consume the milestone-30 coordinate from an unmerged branch.

The eight per-platform uploadJni publishes — the exact jobs that failed on master in 117007595 — all passed:

Job	Result
PublishMacOsAarch64Snapshot	✅
PublishMacOsAmd64Snapshot	✅
PublishLinuxAmd64Snapshot	✅
PublishLinuxAarch64Snapshot	✅
PublishLinuxAmd64Ncurses6Snapshot	✅
PublishLinuxAarch64Ncurses5Snapshot	✅
PublishWindowsAmd64Snapshot	✅
PublishFreeBsdAmd64Snapshot	✅

For comparison, the same step on master failed with Could not get unknown property 'archivesBaseName' (see the build problem on 117007587).