[GRADLE-3136] AbstractProject.getTasksByName(String, boolean) explicitly calls evaluate() Created: 16/Jul/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 0



I have a plugin where I have added:
println ("before afterEvaluate")
project.afterEvaluate {
println ("in afterEvaluate")

directly in the apply method.

Although I call project.afterEvaluate() in my unit test,
the first output is written to console, but the second not.

Comment by Gradle Forums [ 16/Jul/14 ]

Are you using the `ProjectBuilder` in your unit tests?

Comment by Gradle Forums [ 16/Jul/14 ]

Hi Benjamin,

Yes, we are using a mechanism that uses ProjectBuilder itself with some additional general methods we have added. But internal we use the following API:

ProjectBuilder projectbuilder = ProjectBuilder.builder()

ProjectInternal project = projectbuilder.withName("myTest").build()

project.apply plugin: 'ourOwnPlugin'



Comment by Gradle Forums [ 16/Jul/14 ]

This works for me with Gradle 1.12. I haven't tried it with 2.0 as well but I'd assume that it works as well.

This my plugin class:

import org.gradle.api.Project
import org.gradle.api.Plugin

class MyPlugin implements Plugin<Project> {
void apply(Project project) {
println ("before afterEvaluate")

project.afterEvaluate {
println ("in afterEvaluate")

This is my test class using the Spock framework:

import org.gradle.testfixtures.ProjectBuilder
import spock.lang.Specification

class MyPluginTest extends Specification {
def project = ProjectBuilder.builder().build()

def "can call afterEvaluate"() {
project.apply plugin: MyPlugin


In the report you should the output from `afterEvaluate` in the tab `Standard output`.

Comment by Gradle Forums [ 16/Jul/14 ]

I tried out your example, this works for gradle 2.0 as well - your right.
So i spend a little bit more of investigation and I find out that we are using

project.getTasksByName('classes', true) in the plugin before the afterEvaluate block which leeds to this behavior.

Can you please double check it?
Do you know a valid fix?

Comment by Gradle Forums [ 16/Jul/14 ]

Hi again,

have you checked it?
Should I open an issue, do you know an workaround?
Can you even reproduce it?


Comment by Gradle Forums [ 16/Jul/14 ]

Yes, I can reproduce the issue with 2.0. This still worked in 1.12. I'd have to have a deeper look at the code to find out what has changed between both versions. I am going to open an issue if it happens to be a bug.

A reasonable alternative is to write integration tests with the help of the tooling API. However, it requires some setup on your end. For a quick start have a look [1]nebula-test.
[1] https://github.com/nebula-plugins/nebula-test

Comment by Gradle Forums [ 16/Jul/14 ]

Puh - I don't think using tooling API is no alternative for us at the moment, because we have to migrate more than 100 tests for this.
Is there another kind of workaround which is less effort?
Otherwise we have to wait for this bug is fixed in 2.1


Comment by Gradle Forums [ 16/Jul/14 ]

Is it correct that you already had these tests written using `ProjectBuilder` that used to work with 1.12? Now that you are trying to upgrade to 2.0, your tests are broken as `afterEvaluate` is not called under certain circumstances?

Comment by Gradle Forums [ 16/Jul/14 ]

We had these tests written using ProjectBuilder with 1.9, and we started to migrate to 1.12 - as I remember they worked with 1.12, too. So now we decided to migrate to 2.0 and skip the step to 1.12.

And now the all tests which wait for extensions to be filled don't work anymore. Even other things are done in afterEvaluate().

Comment by Gradle Forums [ 16/Jul/14 ]

I had a chance to have a look at the code in 2.0. The method `getTasksByName` explicitly calls `evaluate`. Please have a look at [1]AbstractProject. This means that evaluation happens before your `afterEvaluate` is declared.

Depending on what you are trying to assert in your test case, you might just want look up the task(s) needed without using the method `getTasksByName`.
[1] https://github.com/gradle/gradle/blob/RB_2.0/subprojects/core/src/main/groovy/org/gradle/api/internal/project/AbstractProject.java#L570

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:40:56 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.