Will declarative gradle support applying plugins defined in a

build-logic

(included build) ? We have a build where all

build.gradle.kts

files are constrained to this form.

plugins {
    alias(libs.plugins.mycorp.kotlin.core)
    alias(libs.plugins.mycorp.ksp)
}

dependencies {
    api(libs.moshi)

    ksp(libs.moshi.kotlin.codegen)
}

i.e. only

plugins { }

and

dependencies { }

allowed. and all the deps are loaded from

.toml

libs.plugins.mycorp.kotlin.core

and

libs.plugins.mycorp.ksp

are plugins from

build-logic

(an included build)

AFAIK yes, at least there were talks about it. But not sure how it will work with removed ability to apply plugins in

.dcl

files - all plugins should be applied in

settings.dcl

🤔 what if I want different plugins applied to different subprojects?

as far as I understand when you call your convention plugin DSL in the

.dcl

- it will trigger plugin application to the project. But better to wait for some details from Gradle side on this topic

What if my convention plugin doesn't have a DSL how to I apply it via

.dcl

?

Plugins defined in

build-logic

are not much different from external plugins, so they can define software types just as well. Currently the way to apply them in DCL is by using the software types. This means that currently they should define a software type. They can reuse another plugin’s model for their own software type, if they only “wrap” another plugin. We are exploring ways to plug additional nested models (handled by the plugin’s build logic) into a software model of another plugin, which should solve the case of adding functionality to another plugin better than introducing a whole new software type for that or reusing another plugin’s software type as a whole. Composition of software models can work well in some cases, too, and that should be possible even now. Overall, plugins should never modify the Declarative software models of each other by their imperative code (as well as their own models, to some extent). Doing so would break the ability of the DCL tooling to “understand” the software model data without running the imperative code of the plugins. We are planning to explore ways to enforce this restriction and ways to express the defaults and their adjustments in plugins in a way that is transparent to the DCL tooling.

define a software type

can you elaborate? link to a doc? If I have a convention plugin in

build-logic

that just adds a fixed set of dependencies and doesn't have any parameters and doesn't need any configuration, would be critical to be able to reuse those via dcl. In one of our builds, we currently have ~500

build.gradle.kts

that only have

plugins { }

and

dependencies { }

(using type safe accessors for plugins, deps, and projects) and nothing else. would be great if there was an straight forward transformation to

.dcl