Gradle 2.4: cannot find 'build' tasks using tasks.matching

Old Forum Archive Bugs
1

We have just upgraded our Java multi-project build from Gradle 2.2.1 to Gradle 2.4. Within one sub-project, we have a custom task that needs to depend on all ‘build’ tasks from all Java sub-projects. We use the following code to achieve this:

project.parent.subprojects.each { subproject -> customTask.dependsOn( subproject.tasks.matching { task -> task.name.equals( 'build' ) } ) }

As of Gradle 2.4, this no longer works - no ‘build’ tasks are found, and therefore the dependencies aren’t set up.

This issue seems very similar to 2.4-rc-2 Possible regression project.tasks, but the solution proposed there does not work for me.

Thank you for any insight,

Tom

2

can you try

project.parent.subprojects.all {}

instead of

project.parent.subprojects.each {}
3

Unfortunately using “all” instead of “each” doesn’t compile for me - I get the following error:

No signature of method: java.util.TreeSet.all() is applicable for argument types:
…
Possible solutions: any(), last(), last(), add(java.lang.Object), add(java.lang.Object), any(groovy.lang.Closure)

However, we have since discovered that the following does seem to work:

customTask.dependsOn { project.parent.subprojects.findResults { it.tasks.findByName(“build”) } }

Is this expected behaviour?

4

sorry,

I meant

project.parent.subprojects{}

thomas.wright wrote:

5

Thanks Rene. However, that last suggestion doesn’t work - the dependencies are still not created. The behaviour we’re looking for hinges on exactly when during the configuration phase the search for the “build” tasks occurs - it looks like that Gradle behaviour has changed between 2.2.1 and 2.4: is this deliberate and known, or a bug?

I’m assuming that the code in my second post above happens to delay the search for the tasks for “long enough” that they actually exist when it happens, but I’m still not clear on exactly why that is.

6

I have also came across this “issue” (I don’t knowi if it was an intended change). The workaround is to use subproject.tasks.names.findAll { it.equals('build') } instead of subproject.tasks.matching { task -> task.name.equals('build') }. Also, this is true for a couple of other tasks (or rules).