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