Can I specify the order of taskGraph.whenReady for projects (and subprojects)?

I have a project “:base” and a subproject “:sub”

 |--- build.gradle
 |--- settings.gradle (include ":sub")
       \--- build.gradle

Both build.gradle files have a


closure, is there any way to make base’s whenReady closure run before sub’s whenReady closure?

Maybe in an awkward kind of way. If you were to add the whenReady closure in the same build file, I think it’ll call them in order added, but that’s an implementation detail. You could also make it so the projects are evaluated in a particular order, so your whenReady would follow the reverse of that order. It seems fragile.

What are you doing in the whenReady that is order dependent? That smells like a problem itself.

I’m using the gradle-nexus-plugin on this build. But it does a “whenReady” at : to obtain usename/password for nexus deployment

I have code in my :base/build.gradle file to ask for this username/password and apply it to all projects

gradle.tasks.whenReady {
    Console console = System.console()
    console.printf "\n\nOSS Sonatype Credential required to upload.\n\n"
      def nexusUsername = console.readLine("Sonatype Username: ")
    def nexusPassword = console.readPassword("Sonatype Password: ")
      allprojects { ext."nexusUsername" = nexusUsername }
    allprojects { ext."nexusPassword" = new String(nexusPassword) }

however, before this can execute, the nexus plugin applied to the :sub project runs through it’s own “whenReady” and asks the user. It kind of defeats the purpose of my whole block.

Ah, that sucks.

Can you open an issue against that plugin? It should behave better in a multi-project build. It should probably only look for credentials on the root project and save them once they’ve been asked for once. I’m sure the plugin author wouldn’t mind a PR either.

To workaround it, you might be able to set the nexusUsername/nexusPassword to something, so the plugins code doesn’t get triggered. And then in your whenReady do a similar check as the plugin, only check for the “something” values. Then instead of configuring new repositories, you’d have to go through each of the already existing repositories (that have the wrong credentials) and fix them. I think that would work, but I haven’t tried anything.