I think Gradle is basically confused because you’re configuring a task (the jar task) within a configuration block of the configuration itself. And that within the configuration block of the configuration, you’re resolving the configuration.
It looks like you’re trying to set the Class-Path
property of a jar file in the manifest using the runtime classpath configuration.
Before going on how to do this properly, let me explain why it’s a bad idea to resolve the runtimeClasspath
configuration like this. The named
method will let you configure the runtime classpath configuration. Which means, you could add dependencies, add “extends from”, set it’s “resolvable” flag, etc… And within that configuration block (remember that there can be many, from different plugins), you are actually resolving the configuration:
c.resolvedConfiguration.resolvedArtifacts
This isn’t right, because you’re actually doing something too early (resolving when the configuration’s configuration (!) is not finished), and that you’ll be resolving dependencies at configuration time (very bad for performance).
Instead, because that’s the jar
task that you want to configure, you should configure the jar task and tell it what you’re going to do:
jarTask.configure {
inputs.files(configurations.runtimeClasspath) // "Hey, to be able to execute and be configured properly, I need the runtime classpath to be resolved
doFirst {
// now I can configure the manifest
def artifacts = configurations.runtimeClasspath.files (or `configuration.incoming.resolutionResult` if you need a better API than just the flat list
}
}
Doing this, the manifest entry is configured at execution time, and the runtimeClasspath
configuration is only going to be resolved if, and only if, you execute that task. There’s currently no API to configure the manifest lazily that I’m aware of, hence why it’s done in a `doLast. But remember: never, ever, try to resolve configurations during configuration phase, especially to configure other tasks. This is doomed to fail.