What's the best sample to explore Declarative Gradle today? I've read https://declarative.gradle.org/docs/getting-started/samples/#kotlin-application but there's a lot of choice there. Looks like https://github.com/gradle/declarative-samples-agp-app is a good starting point?

Regarding the new extensions: I have a code generator (kfx) that (obviously) generates code from a OpenApi file via a task and the task is wired via sourceSets.main.java.srcDir(myTask) to support the generation of client/server code for main and test sourceSets, like if you only need a client library but want to have a mock server in your tests, or vice versa. How should it work with declarative dsl and what’s the expected user experience? Should I extend the base software feature like: javaLibrary and register my extension kfx? How should I wire the generated code with the sourceSets? Or could I extend the a SourceSet/SourceDirectorySet, if possible?

👋 Hello, team!

Hi eveyone

Is

Settings.defaults

something about DCL? I wonder reading about it in the Upgrading from 8.13 and earlier section, and that there are changes from 8.10, while it was nowhere mentioned before, also not in the 8.10 release notes, and from looking at it, it seems related to DCL. If so, maybe it should maybe be explicitly marked as DCL-related in the upgrade notes?

Gradle 9.3: What’s the difference between definition and buildmodel? Definition is used for the user dsl, while buildmodel is used for IntelliJ?

With the new service injection and the removal of project access, how do you apply (old) plugins? Especially during a transition period, it could be necessary to support regular plugins and features.

Hey. Is there documentation already, or a good example, that shows how to design my own DSL (aka Project Type) with DCL? I would like to understand what the things are I am supposed to use if I want to do this really clean, without anything that only "bridges" something existing into DCL (which most of the implementations in the declarative-gradle repo do IIUC). If I have a

BuildModel

as entry point, what should I use to implement the structure of my DSL inside it? I basically already have the "grammar" and now I wand to "implement" it with DCL in the most idiomatic/minimal way possible. But I can't seem to find the answer to basic questions like: • Do I use

new

or should I inject

ObjectFactory

(or should I never have to instantiate anything myself anymore?) • Do I still need

Property/Provider

? And if yes where (

String

vs

Property<String>

) • When do I need which annotation (such as

@Nested

and

@Adding

) • Is

NamedDomainObjectContainer

something like a standard that should be used? Or can/should I use my own clean data structures? • What's managed by Gradle and what do need to implement "by hand". E.g. would I do

action.execute(element)

in my code or is that already a sign that I am doing something "wrong", because in DCL Gradle can do these things for me. • ... The problem might be that I am thinking too much in traditional Gradle terms. I am coming from the metal model where I design a DSL with traditional Gradle extensions. There I always follow certain patterns to have a "block" in the DSL - like

public void blockName(Action<BlockType> action)

. I have difficulties to understand what should be done different when doing the same with DCL. Sorry if this is a stupid question. 🙂

I have a MapProperty<String, String>. How can I assign a String key with a Gradle Property as a value:

myMap += mapOf(„foo“ to providers.gradleProperty(„bar“))

Is something like this currently supported in

settings.gradle.dcl

?

dependencyResolutionManagement {
    versionCatalogs {
        create("ktorLibs") {
            from("io.ktor:ktor-version-catalog:3.4.2")
        }
    }
}

Would non lambda function call be supported? I think in the future it will be really normal applying plugins without any configuration as

defaults

is enough:

// settings.gradle.dcl
defaults {
    semver {
        tagPrefix = "v"
    }
}

That will end up with a lot of empty lambdas (depending on the formatter, they can be expanded and wasting vertical space.

// build.gradle.dcl
semver { }

I think

semver()

or

semver

should be supported. Indeed the default formatter is already changing it to

semver {
}

Will it be impossible to have custom functions to be called inside of dcl even if they receive only basic params? Looks like everything around this has been deleted or is internal (for example,

implementation(…)

can be used but the APIs are internal).

@Tapchicoma you published an experimental version of a Kotlin ecosystem https://github.com/Kotlin/declarative-gradle-jetbrains-ecosystem-plugin Will it be a experiment or do you accept issues and pull requests?

Definitions and so on, only works in DCL? I mean, if I reimplement Hubdle and it is working perfectly in DCL, that DSL could be used in kts so I do not need to maintain two implementations?

Another use-case for ProviderExternalModuleDependency support: https://github.com/gradle/gradle/issues/37814

interface DependenciesExtension : Dependencies {
  val api: DependencyCollector
  val implementation: DependencyCollector

  val myLibVersion: Property<String> // has a convention value

  fun libA(): Provider<ExternalModuleDependency> {
    return myLibVersion.map { dependencyFactory.create("org.example.foo:bar:$it") }
  }
  fun libB(): Provider<ExternalModuleDependency> {
    return myLibVersion.map { dependencyFactory.create("org.example.foo:baz:$it") }
  }
}

What will the future of settings plugins be? Should they only be used as ecosystem plugins that does not do anything in the settings phase as

defaults

is possible now? Relatively unrelated to Gradle Declarative, but settings plugins helped to just aggregate all modules into one when you want to aggregate without having to manually put all those

foo(implementation(...))

in that module (Dokka, etc). Would we get some way to "auto aggregate" the relevant modules into one on those cases, or should we keep doing the wire in a settings plugin? If this is the case, some utility function that does the trick easily (and with project isolation support) would be really nice.

If you see this file, there is a "complex logic" that will not be possible with DCL. I was thinking about using an Enum to model those options when you want to attach the Kotlin Version to the normal semantic versioning generated by the semver plugin. Something like:

kotlin
semver {
    tagPrefix = "p"
}

kotlin {
    semver {
        mapVersion = Semver.Version_KotlinVersion
    }
}

But maybe there is a better option to model this. Any suggestion?

How do you apply convention values to the Definition? All the values are finalized when calling the

apply

method. Of course I could create an unsafe Definition but I would like not. What about adding a default method to ProjectFeatureApplyAction called

convention

to add convention values to the definition before the script is evaluated?

The

@Builder

pattern in DCL cannot chain two function calls? I am able to do

foo = bar
    .baz(...)

But if I do

foo = bar
    .baz(...)
    .quux(...)

it fails with

ValueFactoryCallWithComplexReceiver

Is it planned to support named params? I really prefer being able to put them in some situations (check images).

Ignore all red errors, the file is inside a resource folder and consumed in a functional test, so autocomplete does not work there.

Currently, any function that returns something like provider or property cannot be assigned to a value. For CLI or environment variables this is not a problem. But I am wondering about my integration with other plugins without having to support them manually. My plugin assigns the

project.version

using a lazy property as it is currently

Any

. If the Android plugin support a

Property<String>

for the version name, I can't assign or reuse the

project.version

or expose a function that just return a lazy property to avoid using it in configuration phase. Obviously, I can support all third party plugins implementations manually in my plugin, but that would be pretty annoying/not scalable. Any workaround for this?

What will the naming be for plugins that are not ecosystem ones and they just add features to other plugins?

plugins {
    id("org.jetbrains.kotlin.ecosystem")
    id("com.example.kotlin.***")
}

Would it have that structure?

***

can be

feature

or

features

?

What's the DCL design to pass an object from NDOC to another element of another NDOC if you need to model a n:n relationship?

packages {
  package("Foo") {}
}
functions {
  function("Bar") {
    package = ???
    package = packages.named("Foo")
}

In Kotlin, I would assign Foo to a variable. But both of them, variable or named is not supported.

Is there any dcl formatter? intellij default one formats the code really bad

What's the point of safe vs unsafe ApplyActions? AFAIK, you an unsafe action has no access to any mutable state (the project) and is side-effect free. But when registering a task via the safe

TaskRegistrar

, you can easily get the attached project instance in a safe ApplyAction:

var project: Project? = null
taskRegistrar.register("hack") {
  project = this.project
}.get()
project!!

Will this hack be "supported" due to

Task.getProject

or do you plan to introduce a safe Task super interface (maybe without antBuilder and property method too)?

What are the features of the VS Code extension for DCL? https://declarative.gradle.org/docs/getting-started/setup/#visual-studio-code Is there a way to get some (basic) code completion? This would be very interesting as code completion for

gradle.kts

files does still not seem to be available.

Is it possible to track somehow the changes related to DCL between releases? https://gradle-community.slack.com/archives/CJWG8VDM0/p1779973791545699

Any issue or PR on GitHub to track version catalogs support?

Hi everyone🎉, I am a Senior Flutter and React Native, Android / iOS mobile app developer with over 9 years of rich experience. As an experienced developer, I want to contribute to your team as well. I am looking forward to hearing from you soon. Thanks Best Regards

Do you have any name convention for 3rd party feature authors? I have a very unique name for my feature (“Gradle for SAP Integration Suite”), but should I always prefix my feature with this name or use a wrapper deep in the hierarchy?