[GRADLE-3249] pluginManager.withPlugin fires before the plugin is actually applied Created: 01/Mar/15 Updated: 03/Mar/15 Resolved: 03/Mar/15 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | None |
| Fix Version/s: | 2.4-rc-1 |
| Type: | Bug | ||
| Reporter: | Gradle Forums | Assignee: | Luke Daley |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
The new PluginManager's `withPlugin` method is completely broken. My understanding is that `pluginManager.withPlugin` should be considered a replacement for `plugins.withId`. Unfortunately, while it waits until the plugin's apply statement is called, it does not wait until the `apply()` method of the plugin exeutes. You can see this in the following example: println 'Before withPlugin.' println 'Before apply plugin' If/when you file a Jira, I have a zip of a project showing that the apply method is never called. |
| Comments |
| Comment by Gradle Forums [ 01/Mar/15 ] |
|
This is the intended behavior. If you require that the plugin's `apply()` method be executed prior to your configuration closure then you should continue to use the `PluginContainer.withId()` method. This new interface was primarily added to support new rules based plugins that are conditionally evaluated. Therefore it made sense to add a new plugin interface which could be used to add listeners that were called upon application of a plugin, not necessarily evaluation of that plugin. |
| Comment by Gradle Forums [ 01/Mar/15 ] |
|
Considering there was never a distinction between application and evaluation in the past, this should be more clear in the docs. Without that context the [release notes]([1]https://gradle.org/docs/2.3/release-n...) and [DSL ref]([2]https://gradle.org/docs/current/dsl/o..., org.gradle.api.Action)) seem to merely imply a replacement (with some improved behavior) for the old `plugins.withId`. Can you clarify the reason for the distinction? Not being familiar with the new rules plugins, I'm struggling to understand what you could even use `withPlugin` for if you can't access anything the plugin provides. |
| Comment by Gradle Forums [ 01/Mar/15 ] |
|
Without going into too much detail, rule source plugins allow Gradle to evaluate only the parts of the configuration model necessary for any particular build. "Legacy" plugins on the other hand, have the entirety of the `apply()` plugin evaluated for every project on every build during the configuration phase. The difference with rule plugins is that model elements are evaluated as they are queried. So when you say "can't access anything the plugin provides" that is only the case for existing non-rules based plugins. Going forward, you would be able to access model elements defined by a rule source plugin using `withPlugin` by placing configuration in a `model { }` block. The release notes are perhaps a bit vague and what is mean by using `PluginManager` "when possible". In this context it means when you are simply keying of the existence of the plugin. |
| Comment by Gradle Forums [ 01/Mar/15 ] |
|
Alright. Thanks. |