Hello, I have the following task to build a fatJar:

tasks.register<Jar>("buildFatJar") {
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
    isZip64 = true
    from(fatJar.map(::zipTree))
    with(tasks["jar"] as CopySpec)
}

This seems to be producing a bunch of deprecation errors in Gradle 7.6.2:

Reason: Task ':project:buildFatJar' uses this output of task ':other-project:jar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0.

I assume that this is due to the

from

clause in the task which explodes all the dependencies of the

fatJar

configuration into the fatJar. How can I make this task compatible with Gradle 8? Thanks!

The

.map

you use is not the one from

Provider

that preserves task dependencies, but the one from

Iterable<File>

. It not only looses the task dependency but is also evaluated eagerly. If you use

fatJar.elements

and work on that, for example call

.map

on it, it should work better I think.

Thanks @Vampire! Giving it a shot

Actually, if you really need to build such a bad practice fat jar, I'd at least use the shadow plugin of John Engelman which at least sails around some of the cliffs with them.

Thanks for the recommendation, I'll look into it. What would be a better-practice fat jar?

Imho the best practice is the not-fat jar, but building proper distributions. :-D The second-best option is doing it like Spring Boot does it.

By distributions, do you mean the distributions built by Gradle's application plugin?

By distributions, do you mean the distributions built by Gradle's application plugin?

For example, yes.

Can't seem to pass elements.map into the from due to:

You can, if you do it right. 😄

from(fatJar.elements.map(::zipTree))

compiles as

zipTree

accepts

Any

, but then fails as you give it a

Set<FileSystemLocation>

and that is what complains, not the

from

.

Awesome! Thanks a lot Björn!

Yes, sometimes. Kotlin DSL was a great improvement there for IDE support. But methods historically accepting any object and then checking the type are of course not too helpful, but cannot easily replaced due to backwards compatibility.

Oh absolutely. Kotlin in Gradle scripts was a godsend. Yes, understood. I would like to see Gradle deprecating Groovy for build scripts at some point though. That would be another boon for productivity

🤷‍♂️

Thanks again @Vampire