This message was deleted.

An explicit

dependsOn

where on the left-hand side is not a lifecycle task is almost always a code smell and not what you should do. Why does the

jar

task needs be run before that task? Does it have the jar as input? Then wire the output of the jar task to the inputs of that task and you get the necessary task dependency automatically.

how can I do that? Something like (pseudo-code from the top of my head)

@Input
val jar = project.tasks.jar.outputs

?

InputFile

, not

Input

and by using

.outputs

you loose the task dependency. Ususally you would have for example a

RegularFileProperty

in the task annotated with

@InputFile

and then wire it from the plugin that registers the task or something like that. Depends on the context.

this is what has been done so far

And you are showing this pile of bad practices because? 😄

to get help to get them fixed of course 😬

Ok, here some notes from a very cursory look: • Do not use explicit

dependsOn

but declare the

jar

task as file input of that task, then you get the necessary task dependency automatically • Also declare all other inputs and outputs properly, so that the task can be up-to-date or maybe even cached if the work it does is heavy • Strongly consider what you log on

lifecycle

level, those are always shown if not run with

--quiet

and any message logged on

lifecycle

makes seeing warnings and errors harder • Do not use

File

constructor with a relative path, this is the wrong thing to do in 99% of the cases in any Java program. This resolves the path relative to the current working directory, which in case of a Gradle build often is the project directory, but also often is not and is in no way guaranteed. Every build that uses that can be considered broken or at best flaky.Ok, • Don't use

project

at task execution time if you ever hope to use configuration cache • Seems you do some platform-specific things there with jars for different platforms or something like that. You should maybe instead learn how to use variants and variant-aware resolution instead, then you can define variants of libraries for different os and resolve them appropriately • According to https://github.com/trustin/os-maven-plugin/blob/master/src/main/java/kr/motd/maven/os/Detector.java#L150-L190 the

os.name

on macOS starts with

mac

or

osx

, and is not equal to

Darwin

. If that is wrong, maybe that lib needs a bug report, but generally it might be a good idea to use the https://github.com/google/osdetector-gradle-plugin which under the hood uses that one But as I said, just a very cursory look 🙂