This message was deleted.

If you use it at execution time of the task, you should also declare it as input to not miss the necessary task dependencies.

I'm actually using it at configuration time (I believe), to build some specialized far JAR. See https://github.com/oss-review-toolkit/ort/blob/ff05b2d8f0db6d0bbcbf123bf596ded88f7e75bd/plugins/package-managers/gradle-plugin/build.gradle.kts#[…]1

I think the issue is, that at execution time, tasks are not executed yet. So you will get the stale jar from the last run if it is around or otherwise it will not be present and filtered out by your

isFile

check. Maybe it would work better with an artifact transform or maybe when using the

shadow

plugin.

Hmm, I though a line like

_configurations_._runtimeClasspath_.get().filter

would be evaluated lazily, at execution time, when all elements of the

runtimeClasspath

are actually present. Is that not the case?

you have to put the task execution logic in a

doFirst

or

doLast

block, otherwise it's all executed at configuration time

instead of doing

.get()

, try using

.map {}

so the Provider isn’t evaluated until necessary, and use the artifacts API

val classpath = configurations.runtimeClasspath
  .map { runtimeClasspath ->
    runtimeClasspath
      .incoming
      .artifacts
      .artifactFiles
      .filter {
        // Only bundle JARs that are not specific to the Gradle version.
        it.isFile && it.extension == "jar" && !("gradle" in it.path && gradle.gradleVersion in it.path)
      }.map {
        zipTree(it)
      }
  }

I don't remember exactly, I've copied from from somewhere 🙂 I believe it's for also getting the JAR contents for this actual project, in addition to its runtime dependencies.

there’s an example in the docs for creating a fat jar, which on the plus side is nice and simple, but on the downside it’s sometimes too simple and Shadow is better If you’re publishing the plugins with the Gradle Plugin Publish Plugin then it this has support for using Shadow https://plugins.gradle.org/docs/publish-plugin#shadowing

While even

shadow

does not cover all edge cases that make fat jars a sin and bad-practice. When I ever start a blog, the first entry will about "the good, the bad, and the ugly, when it comes to fat jars" 😄

Thanks for pointing out the official example to me @Adam, looks like the lazy evaluation by wrapping

runtimeClasspath.get()

in

{}

inside

from()

is they key...