Add support for Gradle Kotlin DSL

[bartekpacia]

This PR resolves #140548. It's based on my work in #118067.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

[reidbaker]

Overall this looks really good. My biggest concerns are related. One is about files being ignored currently that we start reading that could/would cause a build failure. The second is about users that are migrating to kotlin and how we can support them having some build.gradle and some build.gradle.kts code at the same time.

[reidbaker]

Consider a doc on this function that says we prefer the settings.gradle.kts over settings.gradle.

Also I think this might cause an issue for customers updating since they could have a settings.gradle.kts file that is being ignored and maybe is malformed and a flutter update would cause their build to break. Let me talk this over with @christopherfujino and the android team.

[bartekpacia]

I added the doc comment.

Re: your concern – it is possible that a situation like that might happen, but I think this would be very rare case. Of course I have no data to back it up - I'm according to my experience and "gut feeling". Like, why would some developer end up with both settings.gradle.kts and settings.gradle?

Personally I wouldn't care about it (with my current state of knowledge).

[reidbaker]

Sorry but we have competing guts, I think it is likely to happen for customers who are mid migration and they wont realize that there are different behaviors. Unlike build.gradle and build.gradle.kts I dont think settings.gradle and settings.gradle.kts are mutually exclusive.

Either way our code should be clear on what we expect.

[bartekpacia]

OK, I get you. Thanks for competing with my gut.

I tested Gradle's behavior when both settings.gradle.kts and settings.gradle exist:

build.gradle.kts

rootProject.name = "gradle-example-kts"
logger.quiet("Hello, the project name is: ${rootProject.name}")

build.gradle

rootProject.name = "gradle-example"
logger.quiet("Hello, the project name is: ${rootProject.name}")

---

Gradle completely ignores settings.gradle.kts:

$ gradle projects
Hello, the project name is: gradle-example

> Task :projects

------------------------------------------------------------
Root project 'gradle-example'
------------------------------------------------------------

Root project 'gradle-example'
No sub-projects

To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :tasks

BUILD SUCCESSFUL in 391ms
1 actionable task: 1 executed

So I think we should follow Gradle's behavior (use Groovy even when Kotlin exists). I'd also print a warning (using logger.error()) since this seems unintuitive to me).

Tested on Gradle 8.5

[bartekpacia]

The same thing happens for build.gradle.kts and build.gradle:

build.gradle.kts

tasks.register("hello-kotlin") {
    group = "fun"
    description = "Says hello from Kotlin"
    doLast {
        logger.quiet("Hello from Gradle KTS")
    }
}

build.gradle

tasks.register("hello-groovy") {
    group = "fun"
    description = "Says hello from Groovy"
    doLast {
        logger.quiet("Hello from Gradle Groovy")
    }
}

---

Running (some irrelevant output omitted):

$ gradle tasks
Fun tasks
---------
hello-groovy - Says hello from Groovy

Tested on Gradle 8.5

[reidbaker]

Thank you for testing, It does make sense that we would try to mirror gradles default behavior and I do think this is good evidence that we DO NOT prefer the kotlin file over the groovy file. I do think that a hard failure could still make sense but I think I have asked you to churn on this enough and we can change the behavior later if we made the wrong call.

[reidbaker]

I think either this variable should be removed and the logger strings below should have this inline or the logger strings should stay the same using the file object and rely on the if statement below to use set buildfile correctly

[bartekpacia]

I went for a variable because that string occured in 3 logger.printTrace() statements and remembered rule-of-3.

I'll go with this:

the logger strings should stay the same using the file object and rely on the if statement below to use set buildfile correctly

I would also add logger.error() so that users who (for whatever weird reason) don't have a build.gradle/build.gradle.kts file will see red text when flutter building. Should this case even be supported? I doubt flutter app build works without these buildfiles.

Wdyt?

[reidbaker]

I wrote some of this code originally and I it is more likely that we have a bug in our code than that the users code does not match the conditions below.

Specifically the regular expressions assume a groovy style syntax. Can you file an issue and put it in a comment here that this code needs to be updated with regular expressions and tests that cover the kotlin case in addition to groovy?

[reidbaker]

I filed #141410 can you add a reference to that bug in this method?

[bartekpacia]

If you mean specifically the _buildAndroidGradlePluginRegExp RegExp that is used in this method (getGradleVersionForAndroidPlugin()), then it works in both Groovy and Kotlin.

[reidbaker]

Please include in the dart doc the behavior if both build.gradle and build.gradle.kts are present.

[bartekpacia]

done in d30b4da

[christopherfujino]

this is a confusing comment. running that script won't update this anyway, right?

[christopherfujino]

or will it, and is the user supposed to run that script then revert the change to this file? If so, I would recommend we update the script instead.

[bartekpacia]

or will it, and is the user supposed to run that script then revert the change to this file?

That's right.

I created #140115 because changing the generate_gradle_lockfiles.dart script and running it is a quite massive change (see that PR's "lines changed"). That's why this comment exists.

[reidbaker]

in that case lets make the comment something closer to "This file is auto updated by dev/tools/bin/generate_gradle_lockfiles.dart, do not merge changes to this file. See #140115"

[bartekpacia]

done in 90c07d3

[reidbaker]

I talked to the android team and here is what they said

I would want an error to be raised that we don't know whether or not build.gradle or build.gradle.kts should be used and for the user to be prompted to specify the specific file that should be used on the command line

Alternatively, a giant warning being printed with a clear indication of which file we are using and how the user could override that behaviour if desired

I am trying to find documentation for what gradle does if you have both build.gradle and build.gradle.kts. I believe it errors. If I cant find documentation then I will just try it and update here.

I think we should lean towards mirroring the behavior of gradle, The flutter android team thinks we should stop and error out or have a configuration option and default behavior (which I understand is significantly more work to land the pr).

[bartekpacia]

I would want an error to be raised that we don't know whether or not build.gradle or build.gradle.kts should be used and for the user to be prompted to specify the specific file that should be used on the command line

I agree. I think that doing sth like logger.error("duplicate gradle files detected") when Gradle file exists in both Kotlin and Groovy is enough for this PR. I can create an issue if we decide to tack on that problem later on.