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

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'

.....

project.evaluate()

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"() {
when:
project.apply plugin: MyPlugin
project.evaluate()

then:
noExceptionThrown()
}
}

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

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?

Hi again,

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

Cheers
Markus

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

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

Cheers
Markus

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?

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().

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

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!

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.