Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested afterEvaluate() calls should not be silently ignored #3411

Closed
lptr opened this issue Nov 7, 2017 · 4 comments
Closed

Nested afterEvaluate() calls should not be silently ignored #3411

lptr opened this issue Nov 7, 2017 · 4 comments
Labels

Comments

@lptr
Copy link
Member

lptr commented Nov 7, 2017

Current Behavior

Consider this code:

afterEvaluate {
    println "Outer"
    afterEvaluate {
        println "Inner"
    }
}

This now prints:

Outer

And the Inner part is silently ignored.

Expected Behavior

There should be a clear warning saying that an afterEvaluate {} hook was added from another afterEvaluate {} hook, and that it has been ignored.

Context

The afterEvaluate {} hook is used in a lot of ways to work around ordering problems, and it's easy to end up nesting two of them. Debugging such issues can be pretty hard.

@bamboo
Copy link
Member

bamboo commented Nov 8, 2017

I wouldn't expect the hook to be ignored at all.

My mental model of afterEvaluate is that all requests will be satisfied asynchronously at some point just as the evaluation phase ends before the next phase begins.

I understand this might pose some implementation challenges but let's not settle for a warning without first evaluating the cost of honoring all the requests.

@lptr
Copy link
Member Author

lptr commented Nov 8, 2017

Good point, @bamboo. I remember bringing this question up a while back, and IIRC the answer back then was that there's a legitimate reason for not executing nested calls. That said, just executing them would also be a way to solve this issue.

@oehme oehme added a:bug in:core DO NOT USE labels Nov 9, 2017
@eskatos
Copy link
Member

eskatos commented Apr 27, 2018

Just faced this while fighting with ordering problems.
Silently ignoring blocks of build logic is both surprising and nonsensical.
Gradle should either honor what the build author writes, or fail if it can't.

bamboo added a commit that referenced this issue Apr 27, 2018
By doing a sort of fixed-point iteration on `notifyAfterEvaluate`
until no more `afterEvaluate` listeners are registered.

See #3411
bamboo added a commit that referenced this issue Apr 27, 2018
By doing a sort of fixed-point iteration on `notifyAfterEvaluate`
until no more `afterEvaluate` listeners are registered.

See #3411
bamboo added a commit that referenced this issue May 4, 2018
By doing a sort of fixed-point iteration on `notifyAfterEvaluate`
until no more `afterEvaluate` listeners are registered.

See #3411
@bamboo
Copy link
Member

bamboo commented May 4, 2018

Superseded by #5200.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants