A modern programming language that makes developers happier.

kotlinlang

image.png

I'm trying to use the build-logic convention to build a reusable modular logic for my `android` project, but I've found that there seem to be two ways to achieve the same result.

The main difference between Image 1 and Image 2 is in their `build.gradle.kts` files. In Image 1, it seems necessary to manually register all written convention plugins, while Image 2 apparently doesn't require this. Additionally, they appear to complete the build logic in different ways: one uses `.kts` script files, while the other uses `.kt` files. What are the differences between these two approaches? :thinking_face:

This is where they encapsulate the `Hilt` logic. In my opinion, the second approach seems more concise, but I haven't seen the `.kts` syntax used elsewhere :thinking_face:

Are there any relevant documents or articles that can explain what kind of approach this is? :pray:

In the `.kt` files you write "traditional" binary plugins in normal Kotlin files where you have classes that implement `Plugin&lt;Project&gt;` and so on.

In `.gradle.kts` files you write so-called "precompiled script plugins". Those look and work almost like normal build scripts with just some minor differences.

The precompiled script plugins are more or less just syntactic sugar over writing traditional binary plugins so that you can more easily write plugins in a form you are used to from writing normal build scripts.

Which approach you use is mainly a matter of taste and you can even mix both approaches, wirting some plugins one way, some the other.

It is correct that with traditional binary plugins you need to manually register them. With precompiled script plugins, those are automatically discovered and setup and their ID is built from the package statement in the file if there is any, plus the name of the file stripped by the `.gradle.kts` suffix.

i got a better understanding ! thanks for your great explanation !

you can also find the description in the Gradle docs
<https://docs.gradle.org/current/userguide/writing_plugins.html#pre_compiled_script_plugin>

<https://docs.gradle.org/current/userguide/writing_plugins.html#convention_plugins>

Did you intend to post two different links?

the intention was there, yes. Edited :slightly_smiling_face:

Well, just to clarify terms, now seeing your edit:

convention plugin =&gt; some plugin no matter how it is implemented (traditional binary plugin, precompiled script plugin, Groovy plugin, Scala plugin, ......) that employs some convention you want to use in multiple places to the places where you apply that plugin

precompiled script pluign =&gt; a plugin written as `....gradle.kts`

Those terms are not really interconnected.
It just happens that often convention plugins are implemented as precompiled script plugins.
And unfortunately that many people tend to confuse the two terms due to that. :slightly_smiling_face:

for me the term “Convention Plugin” means anyway that I have several plugins, i.e. on android I have the AGP and the KGP, and I create a “convention”  that unifies the configuration for both so I can easily apply the same configuration on several modules with this new custom “Convention Plugin”.

Yeah, sure.
A convention plugin can just do some configuration, it can do so for one plugin or for multiple, or it can apply one plugin or multiple and configure them, .....
Whatever the conventions are you want to employ.