https://gradle.com/ logo
Join Slack
Powered by
Trying to sanity check that I understand the gradl...
# community-support
c
Trying to sanity check that I understand the gradle lingo here A precompiled script plugin can be a convention plugin. so all convention plugins are precompiled script plugin but not all precompiled script plugin are convention plugins. A precompiled script plugin goes into 1 of 2 spots ā€¢ dedicated 
buildSrc
directory in your build ā€¢ separate included build (can be named 
build-logic
for example but an included build is also == composite build
m
This has entries for 
precompiled script plugin
and 
convention plugin
A 
composite build
is a build that includes at least one 
included build
Would be nice to add the definitions there
c
tony is the šŸ thank you!
šŸ 1
e
all convention plugins are precompiled script plugin
No, you can have a binary convention plugin
ā˜ļø 1
šŸ¤Æ 1
plus1 1
m
+1. I like binary ("regular") better actually because it's faster
e
That's only if it's part of your build. I keep my general use ones in a separate repo that's published to avoid this issue. For project specific plugins, I either set up a private repo, or I publish them to an in project mavenLocal (i.e. I point the mavenLocal repo to a 
.m2
directory in my project).
c
lol. this stuff is wild. I have an app module. and library1 and library2 android-library modules. all i want to do is share
Copy code
plugins {
  alias(libs.plugins.android.library)
  alias(libs.plugins.kotlin.android)
}
and
Copy code
android{
kotlinOptions {
  jvmTarget = "11"
}
}
between them to reduce duplication. (of course more will likely be shared in the future) I'm using the docs from https://docs.gradle.org/current/userguide/pre_compiled_script_plugin_advanced.html#structuring_precompiled_script_plugins and https://docs.gradle.org/current/userguide/best_practices_structuring_builds.html#favor_composite_builds but no matter how much i bang my head against it. i cant get it to work. hence why i started back at the fundamentals of trying to figure out what the heck composite/convention/included builds are. }
e
Are you creating your precompiled script plugins in a included build?
m
That's only if it's part of your build
Do you have more details about this? If you move your plugins to a separate repo, it just moves the slow part to that separate repo? Or is there more to it?
e
It essentially makes them 3rd party plugins. They're published to mavenCentral, so everything is built by the time my project uses it (and I don't have the overhead of an included build)
m
Sure but building your plugin using 
kotlin-dsl
and precompiled scripts plugins is still slower than building it with 
org.jetbrains.kotlin.jvm
and regular binary plugins
e
True, but I very rarely make changes to it, and it doesn't impact my main project build speed
m
Yep, I think Tony mentions that in the herding elephants article as well šŸ‘
It's a big requirement for a simple project though
I like 
build-logic
+ 
org.jetbrains.kotlin.jvm
, it's good enough and doesn't require a separate build
e
True, but I've found that included builds end up impacting overall build times more often than I'd like.
m
Yea, the worst part is you pay the price during configuration time so it's harder to avoid.
But for a newcomer perspective to the whole thing, this would be my recommendation
Not using 
kotlin-dsl
, you'll have to "unlearn" a bit of the Kotlin DSL syntax but I find that this is a feature, not a bug, because you'll need to understand how these things work at some point anyways.
Copy code
plugins {
  alias(libs.plugins.android.library)
  alias(libs.plugins.kotlin.android)
}
You'll have to replace this with something like (untested pseudo code)
Copy code
class MyPlugin: Plugin<Project> {
  override fun apply(project: Project) {
    project.pluginManager.apply("com.google.android")
    project.pluginManager.apply("org.jetbrains.kotlin.android")
  }
}
I forgot the situation about using version catalog aliases in precompiled script plugins
Probably @Colton Idle will hit https://github.com/gradle/gradle/issues/15383
e
so it's quite doable to use the 
dependencyResolutionManagement { versionCatalogs { create("libs") { from(files("../gradle/libs.versions.toml")) } } }
trick in your included build's settings, and then it's just a matter of working around https://github.com/gradle/gradle/issues/35222 to get the plugin versioned in the dependency
as documented in https://docs.gradle.org/current/userguide/version_catalogs.html#sec:buildsrc-version-catalog (and works for non-buildSrc included builds too)
c
a lot of this is admittedly going over my head. Let me re-read this a few times... but I'm starting to think it might be easier to duplicate code. lol FWIW, what got me back on this horse was this video
and it looked so simple in the video. lol
m
Good news is your are soon the dedicated build person in your organization šŸ˜„
ā˜ļø 1
c
yeah... maybe even more of a reason to not learn this stuff šŸ˜‚
would you say that nowinandroid is a good ref for how i should do it? or androidify maybe?
m
Yea, nowinandroid is a good resource
I see last commit from Aurimas, 2 days ago, probably won't do any better than that
c
cool. ill see if i can quickly copy NiA setup
11 Views
Open in Slack
PreviousNext
Powered by