https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Side note: Don't use 
subprojects
block at all
l
Is there a replacement for 
subprojects
block? I have multiple 
android.application/android.library
modules and I would like to disable the lint task for only the debug variants in these modules.
v
Actually practically any 
subprojects { ... }
, 
allprojects { ... }
, 
project(...) { ... }
, 
configure(listOfProjects) { ... }
, and similar should be avoided due to various reasons, reaching from being non-idiomatic in current Gradle, over hindering more advanced features like parallel execution or configuration cache by introducing coupling between projects, to decreasing build maintainability. The way to go is to have convention plugins where you define the common logic and then apply these convention plugins in the concrete build script where you want it to be applied.
l
Is this something related to 
configuration avoidance
? I have read about it and there are some specific APIs that should be avoided. I hope gradle makes all the old APIs deprecated sometime, really confusing. I guess convention plugins are precompiled script plugins right? Do I have to use 
buildSrc
folder to apply these plugins in my current project or is there another way? Would be great if I have the plugin code in my current project and not in a standalone project which I have to maintain separately.
t
I guess convention plugins are precompiled script plugins right?
"convention plugins" are plugins that set up conventions (rather than "add functionalities"), "precompiled script plugins" are one way to write them.
Nowadays I'd rather use included builds (in settings.gradle: 
pluginManagement { includeBuild("…") }
) than 
buildSrc
, but yes, that's the idea: keep them in your project unless you have a good reason to do otherwise.
l
Thanks Thomas. I'm not a fan of 
buildSrc
but to clarify: when I want to write such plugins in my current project, buildSrc is my only option?
v
No, he just told you that you can use an included build which he and me prefer over 
buildSrc
And no, totally unrelated to configuration avoidance
l
But isn't 
includeBuild
always an external project?
v
Depends on how you define 
external
l
Standalone project which needs its own repository for maintenance
v
It is a separate build just like 
buildSrc
, but there is nothing hindering you too keep it in the same VCS. I for example often use 
gradle/build-logic
as alternative to 
buildSrc
Composite builds are nowadays also a way to structure a complex build tree.
l
ahh ok so you create a folder structure in your project with the path ../gradle/build-logic and there relies your build that hosts the plugins, is that right?
v
No, not 
..
l
Sorry I mean rootProject/gradle/build-logic
👍 1
v
Copy code
Myproject
  gradle
    build-logic
      build-logic.gradle.kts
      settings.gradle.kts
    wrapper
      gradle-wrapper.*
  src
  build.gradle.kts
  settings.gradle.kts
l
You are the best ❤️
@Vampire maybe a trivial question but I just reviewed this older discussion and was wondering if it is legit if I just have a simple convention/precompiled script plugin like this:
Copy code
import org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask


tasks.withType<KotlinCompilationTask<*>>().configureEach {
    // Material3 is stable but most of its components are still likely to change
    compilerOptions.freeCompilerArgs.add("-opt-in=androidx.compose.material3.ExperimentalMaterial3Api")
    // Belongs to DialogProperties class
    compilerOptions.freeCompilerArgs.add("-opt-in=androidx.compose.ui.ExperimentalComposeUiApi")
}
I then apply this plugin to multiple other precompiled plugins to avoid redundant code instead of placing it within a 
subprojects
block in the root build.gradle.kts file. Following this practice might end up with a lot of precompiled script plugins with a few lines of shared logic code. Would you say this is encouraged/good practice or is it better to have fewer plugin files but with redundant code?
v
Interesting, how were you able to actually get to this conversation, as it is older than 90 days? o_O However you like but I'd say more small plugins and less duplication is preferable.
👍 1
l
I can review all of my Threads even those from 2021. It's in the top left part of the Slack Desktop app but I think it's also present in the web version of slack Thanks for your opinion :)
v
Ah, right. Forgot that the threads stay available.
2 Views
Open in Slack
PreviousNext
Powered by