Use buildSrc (or a similar build logic) to abstract imperative logic

[FRodrigues-BrandenPT]

Hi,

First I want to congratulate you on this amazing project that tries to organize some of the many interfaces of the Gradle plugin ecosystem.

But, tell me if I'm wrong, in a normal protect, using your suggested structure, I would get an enormous build.gradle, with many configurations and logic. To solve that problem the Gradle documentation (and a large part of the community) advises using a buildSrc. In my project, I created many plugins configuring like liquibase, jib, detekt among others, and also development and production build profiles. That way I get a small build.grade, I know where the general configurations of the many that I use plugins are, and finally, I get a lot of flexibility to apply only the plugins that I want in the subprojects that I also want.

I know that now using buildSrc can influence a lot the performance, but the Gradle team is trying to solve that, or we can now use a composite build with plugins like it was a buildSrc.

What do you think?

[aalmiray]

It depends, on how you structure your build around plugins. I'm currently applying the idea of a Maven POM and parent POMs using Gradle plugins, as explained at https://andresalmiray.com/gradle-poms-revisited/

This results in smaller yet richer build files as shown by the build of this project itself and other projects found in the Kordamp organization. The org.kordamp.gradle.parentbuild plugin is found at https://github.com/kordamp/kordamp-parent

Defining plugins in buildSrc only affects a single project, the one that owns said directory. If you want to reuse configuration then you'd need to publish a plugin to avoid code duplication. This is exactly how the Kordamp Gradle Plugin suite was born years ago, to stop copying script files from one project to the next.

In the end it's all plugins, no matter where you put them. It's up to you to decide where you want to define, declare, and apply them.

[FRodrigues-BrandenPT]

Yeah, I was thinking of a Monolithic or Modulithic project like your documention suggests. I didn't know that buildSrc would only apply to the same directory project because I was using a monolithic design but now I'm trying to change to a modulithic.

But even with that information my point still maintains albeit instead of using a buildSrc using a composite build for build logic configuration plugins like this (taken from this guide):

.
├── build.gradle.kts 
├── settings.gradle.kts // The root project
├── subprojects
│   └── example
│       ├── src
│       └── build.gradle.kts
└── plugin-build        // Composite build with the build logic configuration plugins 
    ├── build.gradle.kts
    ├── settings.gradle.kts
    └── exampleconfigplugin
        ├── build.gradle.kts
        └── src

The only problem is that we (I think) are going to have duplication in the settings.gradle.kts but that can be solved with some scripting. Of course, there's nothing in this project that prohibits someone to organize this way. But I think that this is a good complementary way for when there's too much build logic in the build.gradle (like using other plugins that you "don't support") and, in my opinion, would be a great addition to your documentation and project.

[aalmiray]

Even though the documentation for Kordamp suggests how to organize a single or multi-project build with opinionated structure it also does not mention how and where plugin projects should be or could be located. Why? Because opinions on this matter vary and just recently as you mentioned the Gradle team has changed their mind and has put forward documentation on binary script plugins. In the past buildSrc was deemed a burden and they wanted to get rid of it; now it's the new darling due to binary script plugins. They might change their mind again in the future.

For this reason Kordamp does not promote or endorse how plugin projects may be associated with a particular build. It's up to each project to decide what's the best course of action based on their needs and expertise.

Furthermore, for the specific structure that you defined, the duplication in settings file can be factored out using yet another plugin (like the kordamp-parentbuild) IF this setup is to be reused by other projects under your control, otherwise this is a one-off build that may not need such refactoring. Also, if the top-most settings file uses the org.kordamp.gradle.settings plugin then you'll have to explicitly skip/ignore the plugin-build directory otherwise it will be automatically added as a subproject to the root, not as a composite. This is due to the autodiscovery feature exposed by the org.kordamp.gradle.settings plugin.

[FRodrigues-BrandenPT]

Thank you, I understand now why there's no documentation talking about this. And also thanks for the tips! Keep up the good work!