Applying settings plugin from source dependency

I’m trying to apply a settings plugin from a source dependency. This is what I tried:

pluginManagement {
    sourceControl {
        gitRepository('path/to/the/repo.git') {
                producesModule('my.group:my-plugin-id')
            }
    }
}

plugins {
    id 'my.group:my-plugin-id'
}

I assumed that pluginManagement is the place to put the sourceControl block because:

  1. Gradle complains if I try to put sourceControl before plugins.
  2. this is where includeBuild() would go when trying to apply a plugin from an included build.

I’m still getting a “plugin was not found”.

If I look at PluginManagementSpec, it doesn’t even have a sourceControl() method, so I don’t really understand why this is even compiling.

I tried various permutations of where to put sourceControl, but none of them work. Is it even possible to use source dependencies in this case?

I don’t think you can.

Regarding having sourceControl before plugins, that would only work with Kotlin DSL.
With Groovy DSL the order of the blocks is constrained and you can only have buildscript, pluginManagement or other plugins blocks before a plugins block.

If you have it inside pluginManagement it workscompiles, because pluginManagement is allowed before plugins, but it will still call the sourceControl of the outer settings script.

But nonetheless it will most probably just not work.
To get a settings plugin from an included build, you need to have the build included not on top level of the settings script, but inside pluginManagement, as for exactly that reason pluginManagement is evaluated separately first so that a settings plugin can come from there.
But the source dependency is basically the Git logic around including the build using the top-level mechanism.

To be able to use a settings plugin from a source dependency, the source dependency feature would need explicit support for that.

What might maybe work is to additionally include the build from the source dependency within the pluginManagement block manually. But I guess the source dependency is evaluated too late to do this, at least on a clean checkout.