Executing code with Project.afterEvaluate() after project is evaluated

1,979 views
Skip to first unread message

Lóránt Pintér

unread,
Jan 14, 2015, 8:52:42 AM1/14/15
to gradl...@googlegroups.com
Hey,

I might be wrong here, but it seems that when I call Project.afterEvaluate() on a project that has already been evaluated, my closure/action does not get executed at all. It would make much more sense to me if in such a case the closure/action would get executed immediately. The only workaround I found to make sure my thing gets executed is to check ProjectInternal.getState().executed() and call afterEvaluate() or action.execute() based on that, which makes the code pretty hard to read.

—
Lóránt

Luke Daley

unread,
Jan 14, 2015, 9:06:33 PM1/14/15
to gradl...@googlegroups.com
The joys of afterEvalute(). 

I’m not sure what weight we would need to give to the backwards compatibility of such a change. I can’t see any use for the current behaviour, so the breakage risk is low.
--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/1421243559824.27b5c11a%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Daz DeBoer

unread,
Jan 18, 2015, 1:14:51 PM1/18/15
to Gradle Development List
An alternative would be to prevent the adding of 'afterEvaluate' actions to an already-evaluated project.

How are you accessing the project that is already evaluated?
What's the use case for modifying the project after it has been evaluated?

Daz


For more options, visit https://groups.google.com/d/optout.



--
Darrell (Daz) DeBoer

Lóránt Pintér

unread,
Jan 23, 2015, 8:36:31 AM1/23/15
to gradl...@googlegroups.com, Gradle Development List
I think I bumped into this several times, when trying to do stuff with sibling projects: because they are evaluated in alphanumeric order, some projects end up being evaluated, while some do not.

—
Lóránt


Luke Daley

unread,
Jan 25, 2015, 9:16:57 PM1/25/15
to gradl...@googlegroups.com



On 19 January 2015 at 4:14:52 am, Daz DeBoer (darrell...@gradleware.com) wrote:

An alternative would be to prevent the adding of 'afterEvaluate' actions to an already-evaluated project.

We do assume in the codebase that once a project has been evaluated we know all we are going to know about it. If we can get away with this, then this feels to be the better option to reduce the spaghetti-ness.

However, I think (based on what I’ve seen) that the kinds of things that users would do in afterEvaluate() that would clash with our assumptions is kinda small. It would probably work for the most part.

Options as I see them:

1. Do nothing (keep current no-op behaviour)

2. Error when adding afterEvaluate() to evaluated project

3. Run afterEvaluate() immediately

Strictly speaking I guess only #1 is backwards compatible. #2 feels the least backwards compatible. I’m in favour of #3, but think #2 is also a decent option.

How are you accessing the project that is already evaluated?
What's the use case for modifying the project after it has been evaluated?

This can happen unintentionally quite easily. A common one is to call evaluationDependsOnChildren() and then do more configuration injection into the children.


Lóránt Pintér

unread,
Jan 26, 2015, 8:55:21 AM1/26/15
to gradl...@googlegroups.com, gradl...@googlegroups.com
I think strict checking (#2) would be great, but it doesn’t sound realistic with the current options for configuration. Maybe with the new configuration model things would be different. So how about a warning + executing the code immediately?

—
Lóránt


To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/etPan.54c5a393.741226bb.d1da%40Trajan.local.

Luke Daley

unread,
Jan 26, 2015, 7:38:24 PM1/26/15
to gradl...@googlegroups.com



On 27 January 2015 at 12:55:22 am, Lóránt Pintér (lorant...@gmail.com) wrote:

I think strict checking (#2) would be great, but it doesn’t sound realistic with the current options for configuration. Maybe with the new configuration model things would be different.

Very much so. Configuration dependencies are taken on individual elements, rather than using the imprecise concept of project evaluation in order to configuration. 

Furthermore, constructs analogous to project.afterEvaluate() are declarative in that we know about them very early in the process and they can’t be declared by anything at anytime.

 So how about a warning + executing the code immediately?

+1



—
Lóránt

Daz DeBoer

unread,
Jan 26, 2015, 8:14:59 PM1/26/15
to Gradle Development List
I've raised https://issues.gradle.org/browse/GRADLE-3231 for this issue, and I guess it is related to https://issues.gradle.org/browse/GRADLE-2514.

Thanks for raising it!
Daz



To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/etPan.54c6ddfa.238e1f29.15904%40Trajan.local.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages