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

Callback to know if the dcl schema has been totally processed. #151

Open
JavierSegoviaCordoba opened this issue Dec 1, 2024 · 1 comment

Comments

@JavierSegoviaCordoba
Copy link

JavierSegoviaCordoba commented Dec 1, 2024

Even if it sounds bad as it remembers to afterEvaluate, here the schema is deterministic, so I would like to have a callback which is invoked when the whole schema has been processed to allow using flags that will be resolved in configuration phase, but not Property, as they are oriented to configure tasks.

For example, based on an enabled flag, I would like to decide if I apply or not a plugin, and that is done in the configuration phase after the whole schema has been processed to ensure nested values modified by the user are already with the correct value in the callback.

Another valid example could be not registering tasks (note: it is not registering them at all, no disable them with onlyIf).

@JavierSegoviaCordoba
Copy link
Author

JavierSegoviaCordoba commented Dec 1, 2024

Another option could be having the concept of configuration Property, oriented to the configuration phase.

@Restricted
public interface Foo {

    @get:Restricted public val bar: ConfigurationProperty<Boolean>
}

// called after the `dcl` has been processed
foo.bar.onProcessed {
    project.pluginManager.apply(...)
    project.tasks.register(...)
}

For this last option, a way to combine multiple options is a must too to avoid multinesting:

// called after the `dcl` has been processed
combineOnProcessed(foo.bar, foo.baz) { bar, baz ->
    project.pluginManager.apply(...)
    project.tasks.register(...)
}

I don't know until which point this reminds me a lot of Kotlin Coroutines. It can be mad, but maybe Gradle could move to using coroutines so it can get the advantage of async + stream APIs, those coroutines would have a lifecycle for each phase or something so.

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

No branches or pull requests

1 participant