What went wrong:
Could not determine the dependencies of task ‘:platform:azure:classPathJar’.
Resolving dependency configuration ‘runtimeOnly’ is not allowed as it is defined as ‘canBeResolved=false’.
Instead, a resolvable (‘canBeResolved=true’) dependency configuration that extends ‘runtimeOnly’ should be resolved.
Well, hard to guess without you showing any relevant code.
But let me repeat what the error already told you.
You try to use the runtimeOnly configuration as input for the classPathJar task and that is not allowed, as runtimeOnly must not be resolved.
Maybe you wanted to runtimeClasspath instead.
Or if you really just wanted the runtimeOnly dependencies, then the error also already told you what to do, i.e. create a new configuration that is resolvable and extends it.
Puh, there is so much suboptimal in this snippet.
Here some points:
update your ancient Gradle version (incremental Java compilation would be enabled by default since 4.10, runtime configuration is deprecated since many many years and since Gradle 7 also removed, so you are on a very old version most probably)
don’t use project.plugins as per its JavaDoc it shouldn’t be used, but either the PluginAware methods on project directly, or in your case pluginManager
don’t use hasPlugin as it imposes an ordering requirement, instead either use pluginManager.withPlugin('java') to react to that plugin being applied even if it is applied later, or first apply the java plugin if it is always required there
as I assumed, you depend on runtimeOnly which is not meant and not supported for resolving dependencies but for declaring dependencies, besides that you depend on it, but not use it at all which also makes no sense
same for runtime, besides that it is deprecated since years it is also not for resolving dependencies, but for declaring, you probably want to use runtimeClasspath instead
do not change the configuration of a task from its execution phase (doFirst), that works against properly working up-to-date checks (and if the task were cacheable would also cause wrong cache entries)
most probably better do not build a runnable jar like that, the built jar is only usable on the machine where you built it or on machines that happen to have your dependencies at the same cache location, and at some point in time, Gradle will also evict cache entries if they are not used by a Gradle build and will then be missing from your classpath. Better use the The Application Plugin to build a proper distributable archive with your code, your dependencies, and generated start scripts for *nix and Windows that properly run it
don’t configure explicit dependencies when you should wire outputs (output of the classPathJar task) to inputs (classpath of the run task), but properly wire the outputs to the inputs, then you get implicit task dependencies where necessary automatically. Almost any explicit dependsOn is a code smell unless the left-hand side of the dependsOn is a lifecycle task
actually, when using the application plugin you already get a properly configured run task where you just have to add your system properties and so on
unless you want to configure args through gradle.properties, don’t use a Gradle property for the args to your program. I guess you intend to use it like ./gradlew run -P args="a b c", simply use the the --args parameter instead like ./gradlew run --args a --args b --args c.
if you care about the upcoming Configuration cache, don’t access all system properties like that, or the configuration cache can practically never be used as any change in any system property would invalidate the cache, instead use providers.systemPropertiesPrefixedBy...