This message was deleted.

2 will be evaluated very late and only fail then if the task really does not exist. 1 fails instantly if the task is not available already. That also means that for 1 you require that "something" is evaluated before the project you have that in and also that it requires that it also is evaluated always if that project is evaluated. So 2 might be a bit safer, but actually, practically any explicit "dependsOn" that does not have a lifecycle task on the left-hand side is a code smell and should be avoided. So unless

taskA

is a lifecycle task, better wire inputs and outputs together and get implicit task dependencies running properly. See https://docs.gradle.org/current/userguide/cross_project_publications.html for proper cross-project publication ways.

Thanks for the input @Vampire! Somewhat related, what if project

:something

is not necessarily available under certain conditions (e.g., project changing configuration from

taskA

is part of an included build that

:something

is not)? Is it possible to conditionally configure

taskA

only if

:something

is present?

Well, yeah, make an

if

that checks whether the project exists. But tbh, that also sounds like a code smell. 🙂

Indeed I agree with you! for now, it's workaround solution for a complex setup, but later on, the plan is to get away with unwanted tasks and unnecessary dependencies. In the end I changed the

dependsOn

relation for

mustRunAfter

to see how it works and I might go with it for now.

I don't think it changes anything in that regard