This message was deleted.

Here’s one of the options, I see (haven’t checked if it works yet):

override fun apply(target: Project) {
        target.rootProject.subprojects { subproject ->
            subproject.tasks.apply {
                val dependencyProjects = subproject.configurations
                    .map { configuration -> configuration.dependencies }
                    .filterIsInstance<ProjectDependency>()
                    .map { dependency -> dependency.dependencyProject }

                val parentTask = register<GenerateMetadataTask>(TASK_NAME)

                dependencyProjects.map { dependencyProject ->
                    dependencyProject.tasks.withType(GenerateMetadataTask::class.java) { dependencyTask ->
                        parentTask.configure { task ->
                            task.dependsOn.add(dependencyTask)
                        }
                    }
                }
            }
        }
    }

It looks like https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:variant-aware-sharing would be a great fit here. When the plugin is applied on a project (avoid cross-project configuration), create a task that generates the metadata and exposes it as a new variant. Also create a configuration with appropriate attributes to resolve that variant from dependencies, and arrange to have project dependencies in there. The hard part here is indeed to understand variant selection, and how to declare your dependencies (you could possibly compute default dependencies from other configurations, filtering to keep only project dependencies; or maybe have the metadata configuration extend all other configurations and arrange to not fail at external dependencies obviously not having the metadata variant, either using a compatibility rule to fallback to another variant, or a component metadata rule to dynamically declare the variant with some dummy artifact)

Or use a lenient artifact view, then dependencies that do not have the variant are simply silently ignored.

Hmm, but wouldn’t this approach harden configuration for the users of the plugin? Or I could setup everything from within the plugin itself?

You should be able to do all you need from the plugin. Only "caveat" is, that you should not do cross-project configuration like Thomas said. So do not configure subprojects just because the plugin is applied to an arbitrary project. Instead let the user decide where to apply your plugin and just handle the situation properly even if the plugin is not applied to all projects. Maybe a user has a dedicated documentation subproject where the plugin should not do anything, or some dedicated system test subproject, or wahtever. The user should have the control where the plugin does work.

Yeah, I suppose that in case of the proposed approach, there’s no need to perform the cross-configuration. It’s just my direct way of translating idea into code. I still wanted to give a way to disable plugin for a certain module via extension in this setup.