Status Update
No update yet.
Comments
dw...@google.com
Met with UX team today and digested their recommendations into this:
This includes both new module and new project wizard cases. Is it ok to track them in the same issue or should we create a separate issue for the new project wizard?
pa...@google.com
"settings.gradle.kts" and project root "build.gradle.kts" implemented by Change-Id: I0f4ff07c9b890d9d0c7b49899de4d63cfbe897a5
(Missing UI for "New Module" and templates for module "build.gradle.kts")
pa...@google.com
pa...@google.com
pa...@google.com
The check box for kts was now added to all "New Modules", the Wizard templates updated and tests added for all entries.
This is an example of current generated code:
=======================================
plugins {
id("com.android.application")
id("kotlin-android")
}
android {
compileSdkVersion(29)
buildToolsVersion = "30.0.0"
defaultConfig {
applicationId = "com.example.myapplication"
minSdkVersion(16)
targetSdkVersion(29)
versionCode = 1
versionName = "1.0"
testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
getByName("release") {
isMinifyEnabled = false
proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
}
}
compileOptions {
sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8
}
kotlinOptions {
jvmTarget = "1.8"
}
}
dependencies {
implementation("org.jetbrains.kotlin:kotlin-stdlib:${rootProject.extra["kotlin_version"]}")
implementation("androidx.core:core-ktx:1.3.0")
...
}
=====================
I think we are tracking the KTS DSL improvements in other tickets, but this is the list of things that are still pending on AGP:
- Properties vs functions: compileSdkVersion(29) instead of compileSdkVersion = 29 (same for minSdkVersion/targetSdkVersion)
- No block for debug/release : Using getByName("release")/getByName("debug")
- Global variables ("ext") ${rootProject.extra["kotlin_version"] is harder to use than groovy
So for now, we will keep the Canary flag off (NPW_SHOW_GRADLE_KTS_OPTION)
dw...@google.com
Jose/Adarsh, is this something we'd be able to target for 2021.1 (per the plan outlined in go/kts-in-studio)?
pa...@google.com
We can enable the flag in Canary and starting showing the "Use Kotlin script" checkbox. But should we address the limitations of the DSL in #6 first?
1 - Just noticed that "debug"/"release" have now their own blocks! Can we remove the getByName()?
2 - compileSdkVersion, minSdkVersion and targetSdkVersion are still function calls (instead of properties). But I can see new(?) properties for compileSdk, minSdk and targetSdk (and minSdkPreview?). Is that right? Should we use that for both Groovy and KTS?
3 - Using variables look the same -> ${rootProject.extra["kotlin_version"]}. Any improvement planned here?
Please let me know, and I'll update the templates and enable the flag.
dw...@google.com
I'll defer to Xav on the DSL updates. I do think you're right that we should address those changes before updating the generated template code, though.
xa...@google.com
-
hmm yeah I think so
-
These are new. I think they are present in 4.2 but the DSL is not stable. In 4.3/7.0 they will be stable. I don't really expect them to change at this point so they are safe to use.
I would use them both for Groovy and KTS, as we will deprecate the old ones in 7.0 (and remove it in 8.0) so the usage pattern is
compileSdk = 30
compileSdkPreview = "R"
compileSdkAddon("vendor", "name", 30)
and same for minSdk and targetSdk
- no changes there. this is Gradle rather than us and no easy fix.
Can you share a project that was created by the wizard so I can review it?
pa...@google.com
Please see attached a default Kotlin with Kts project as generated from Main.
dw...@google.com
@Jose can we enable the NPW_SHOW_GRADLE_KTS_OPTION flag in Arctic Fox?
As far as behavior goes, I believe the plan of record was to have it be default unchecked in all cases unless it's a new module where users are already using KTS.
pa...@google.com
Just uploaded CL's to fix #11 and enable #12 (pending review).
#8.3 Was now work-around for koltin-version (we don't need this var anymore), but is still showing in projects that use variables (like a compose project).
Also noticed we have a new "debug"/"release" block for buildTypes, so we don't need to use getByName("release") anymore! Awsome.
@David I think we can enable this in Canary, but we should have someone on QA taking a good look at this before release (not just if new Projects/Modules build, but also if there is any impact on build speed and if the build files are "idiomatic").
I'm attaching a couple of projects generated with the latest changes.
dw...@google.com
Thanks Jose. Dumb question — what is the process for doing that? Do we need to create some kind of test spec for the QA team?
pa...@google.com
saurabhc@ maintains a list of the go/no go features ->
For the QA, in this specific case, they should test the same scenarios they already do when they create new Projects/Modules (The test spec is just a google doc saying that - with a screenshot that shows the check-box?)
For the "idiomatic" bit, we need someone that knows a lot about kts and takes a look at the generated code. I would says someone on xav@ team?
dw...@google.com
Thanks!
Saurabh, would you know how we can dig up the test spec for the project/module templates? Per Jose's guidance would be good to update so we test for both Gradle and KTS.
sa...@google.com
Here is the most recent test spec I found for the NPW:
Jose - Can you please help review if that's still accurate and add additional screenshots/steps needed to manually verify the .kts support?
pa...@google.com
#17 Document looks OK. I made a new copy and updated the test description and screenshots:
Saurabh (or David?),
sa...@google.com
Thanks Jose, yes we need to have a consolidated test spec for the feature.
@David - who is working on this on the Sync/AGP side so that we can ask for their help with further updating the test spec?
dw...@google.com
xof@ is probably the right contact for that (adding him to cc).
sa...@google.com
Hi Christophe,
Can you also help update the below test spec document to include any Sync changes that should be tested for the full KTS support launching in Arctic Fox? Many thanks!
xo...@google.com
I've added a "General IDE support" section, explaining what I think is the overarching principle and giving some examples. I hope it's clear enough!
Description
Checkbox can be unchecked by default.