From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

For example, I see that `java-library` plugin uses first one :thinking_face:

I also don’t know what the underlying difference is, but the docs advise to use the first one
&gt; While not deprecated, it is preferred to use the methods of this interface or the `plugin manager` than use the plugin container.
<https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/PluginAware.html#apply-groovy.lang.Closure->

from the code I see it is mostly the same, just `PluginManager` calls `doApply` via `apply` and `PluginContainer` calls `PluginManager.addImperativePlugin`  which also calls inside `doApply`

So seems there is no difference :man-shrugging:

Looks like legacy code that will be deleted some day so I would use plugin manager 

agreed.  though that unfortunately leaves inconsistent code:
```pluginManager.apply(...)
plugins.withType&lt;...&gt;```
…as there is no withType equivalent on pluginManager.

<@UACGKT8S1> importing `org.gradle.kotlin.dsl.apply` allows removal of ‘.java’, e.g. `project.pluginManager.apply(JavaPlugin::class)`

…and this other neat Kotlin syntax allows removing ‘project.’:
```override fun apply(project: Project): Unit = project.run { }```

…and some more DSL / extension functions on Project allow for:
```apply&lt;BasePlugin&gt;()```

<@U02S31Y7J2K> why would you want to `plugins.withType(&lt;type::class&gt;)`  vs `pluginManager.withPlugin("&lt;id&gt;")` ?

Well behaved plugins should set up some extensions or tasks or some other model and be done. You shouldnt need the actual plugin instance for anything (most of the time). Imo, its becoming _more_ consistent by recommending to use the plugin manager together with ids :shrug: