hello

Is it possible to use IDEA instead of AS? I cannot find the flags on IDEA

• the

gradle.declarative.studio.support

and

gradle.declarative.ide.support

flags

I would like to add a custom configuration for the

KotlinSourceSet

, but as I cannot inject

Project

or

ExtensionContainer

in my class, the only way to configure it is by duplicating a lot of things from the

KotlinSourceSet

I want to be able to do something like you can see in the image. Is there any way to get any plugin Extension inside a

@Configuring

method?

FYI We just uploaded a new version of Android Studio with Declarative support provided by Google that fixes several issues that were showing in

settings.gradle.dcl

files. You can find it in the Google Drive linked here https://declarative.gradle.org/docs/getting-started/setup/#ide

Builds of IntelliJ IDEA with support for DCL are out 🎉 https://declarative.gradle.org/docs/getting-started/setup/#intellij-idea

Is it possible to access the software model from one plugin to another? It is in normal Kotlin files, not in

.dcl

files. The use case is configuring the X plugin from the Y plugin without having to create a middleware project extension or something similar which complicates the setup a lot.

When enabling

org.gradle.kotlin.dsl.dcl=true

using 8.12-20241129001902+0000, I always get some parser (or even lexer) errors in my kts files, also when using a very simple gradle init sample project. Should I create an issue or is the DCL implementation too experimental?

I am able to test dcl plugins using Gradle test kit without any issue. But I need to configure a project with additional data not supported by dcl, so I need to use

org.gradle.kotlin.dsl.dcl=true

but then tests are failing with:

ScriptCompilationException(scriptCompilationErrors=[...])

Is there any workaround?

👋 大家好！

This message was deleted.

How do you plan to support extensions of objects in DCL? Without DCL, I have a top-level extension myExt provided by my base Gradle plugin, and some Gradle "sub" plugins adding an extension to the myExt like

myExt.feature1 {}

or

myExt.feature2 {}

. With KTS, there are generated accessors but AFAIK the DCL uses the static software type and not the dynamic extensions registered during runtime. Or should I create a new top level extension for each "sub" plugin?

A problem occurred evaluating settings 'TikTok'.

> No signature of method: org.gradle.api.internal.artifacts.ivyservice.dependencysubstitution.DefaultDependencySubstitutions$1.with() is applicable for argument types: (org.gradle.internal.component.external.model.DefaultModuleComponentSelector) values: [com.google.guava:guava:30.1-jre]

Possible solutions: with(groovy.lang.Closure), with(boolean, groovy.lang.Closure), wait(), wait(long), find(), wait(long, int)

Does anyone know how to solve this?

image.png

This message was deleted.

Since yesterday, support for

.gradle.dcl

files is now included in regular Android Studio nightlies. It is not needed to download a special nightly from an obscure Google Drive. https://developer.android.com/studio/nightly Note that you still have to enable the Declarative features as explained here https://declarative.gradle.org/docs/getting-started/setup/#enable-declarative-features-in-studio

New builds of IntelliJ IDEA have been made available by JetBrains Today https://declarative.gradle.org/docs/getting-started/setup/#ide

@Paul Merlin When using DG, you need both

settings.gradle.dcl

and

build.gradle.dcl

? For instance, is it still possible to have

settings.gradle(.kts)

, but then have

build.gradle.dcl

?

Declarative Gradle Roadmap was released last week, I think it was never posted in this channel https://declarative.gradle.org/docs/ROADMAP/

With

org.gradle.kotlin.dsl.dcl=true

it is possible to use the custom parser for software types in kts build files. Will it also be possible to enable the custom parser for software types in precompiled kts plugins in buildSrc? Use case: I don’t want to pollute my settings.dcl with many default values but write precompiled settings plugins and not using KotlinCompile would make this use-case faster.

This message was deleted.

Extra Q&A chat is live for the Declarative Gradle webinar we are streaming now: https://gradle.com/events/Declarative-Gradle-developer-first-approach-to-Gradle-builds-04-25/

Is there any new information about "lazy properties" to allow creating DSL in Gradle Declarative to apply plugins or create tasks conditionally without ordering issues? It would be nice if this issue was solved in Declarative Gradle, as currently even you can get it more or less working, sometimes you are forced to use

afterEvaluate

as the workaround which is bad.

Which Gradle is better? Kts or dcl

How can I register a custom maven repository in settings.dcl? Do I miss something or is it not yet supported?

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?