<@U8HQP86P6> The think the main goal of the plugin...

# gradle

[StefMa]

@xenoterracide
The think the main goal of the plugins block was to make it easier to apply plugins as with the buildscript block.
But that canes with "some limitations". The plugins block look only for "core Plugins" and to the plugins Portal at plugins.gradle.org.
All plugins which are deployed to the Plugin Portal can be used without the settings.gradle.
So yes, you always have to to use the "hard way" to add plugins from another Repo than the plugins portal.

[flstaats]

Our solution was to create a standard init.gradle script at the corporate level that injects a pluginManagment block into every settings.gradle. This code maps projects to both plugins.gradle.org (including doing the funky metadata mapping from the undocumented rest service) and our internal plugin repositories. As a side effect we added a global mapping file that is downloaded and cached that maps symbolic version names (e.g. CURRENT, TEST, etc.) to centrally defined versions. We also remap all external repositories for both plugins and projects to our approved internal mirrors. We were able to do this once and projects don't need to have a pluginManagment block defined in them.