When running gradle on this project I get the following message:

The Kotlin Gradle plugin was loaded multiple times in different subprojects, which is not supported and may break the build.
This might happen in subprojects that apply the Kotlin plugins with the Gradle 'plugins { ... }' DSL if they specify explicit versions, even if the versions are equal.
Please add the Kotlin plugin to the common parent project or the root project, then remove the versions in the subprojects.
If the parent project does not need the plugin, add 'apply false' to the plugin line.
See: https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl
The Kotlin plugin was loaded in the following projects: ':application-plugins', ':base-plugins'

This sounds bad. Is it bad?

When using a gradle plugin (internal or external such as detekt) it can sometimes inject implementations at the top of the list. These can 1) have a version and 2) aren't injected in the correct order so the version checking and order checking features of the analysis plugins don't really work.

Is there a way when doing the filtering (https://github.com/jjohannes/gradle-project-setup-howto/blob/87c42549a63e13933e35db960132eda869f632b9/gradle/plugins/dependency-analysis-plugins/src/main/kotlin/org.example.dependency-analysis.gradle.kts#L12-L19) to ignore injected depedencies?

Just how special :app is not clear from the documentation.

Process to reproduce.

• [ ] clone the project's git repository
• [ ] git mv app foo
• [ ] ./gradlew build -> see error below

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':bespin:compileJava'.
> Could not resolve all dependencies for configuration ':bespin:compileClasspath'.
   > Project with path ':app' could not be found in project ':bespin'.

Resolution:

• [ ] change :app to :foo in two files
  • [ ] ./gradle/plugins/base-plugins/src/main/kotlin/org.example.consistent-resolution.gradle.kts
  • [ ] ./gradle/plugins/base-plugins/src/main/kotlin/org.example.root.gradle.kts

This may be the intended behavior but it was not what I expected. The documentation around :app including dependencies should get some attention. My specific issue was that I created an application with a different name. It was unable to resolve any dependencies unless it shared that dependency with :app.

Seems like this will start sending data to scans.gradle.com for anyone that clones and builds the project without them accepting the terms of service?

https://github.com/jjohannes/gradle-project-setup-howto/blob/8f7ec35e2a44724824b9f2ffd29e4da984591983/gradle/settings/src/main/kotlin/org.example.settings.settings.gradle.kts#L35-L41

My suggestion would be to just remove that block completely and let people gets scans with --scan if they want them. (or they can add in a config like above if they want that)

I have a Kotlin project. Do you have an example like gradle-project-setup-howto with a kotlin-plugin convention? I tried to modify https://github.com/jjohannes/understanding-gradle/compare/main...phreed:main but it does not seem to be correct.

Hello Jendrik,

I hope this is the appropriate forum to ask this question.

We have a large multi-project build, following much of the best practices outlined here and in the Gradle User Guide but I am struggling to understand the best practices for applying plugins to our conventions.

There are two ways in which I've applied plugins to our projects:

1. Create separate convention plugins for each variant of the plugins to apply, as this repository has done under gradle/plugins/java-library-plugins

       In this case, I could end up with a considerable amount of conventions such as:

java-library-with-text-fixtures java-library-published java-library-with-jmh java-library-with-text-fixtures-and-jmh java-library-published-and-jmh java-library-publish-with-text-fixtures-and-jmh

2. Apply all the common conventions to all java-library projects

       In this case, I would minimize the amount of conventions plugins I need to write and when a developer creates a new subproject, simply applying java-library will give you access to things like JMH and Test Fixtures already configured and ready to be used.

       The issue I've found with using this technique is that the configuration time can be dramatically increased throughout the project. There might be subprojects that don't use JMH or Test Fixtures even though these plugins are being applied needlessly increasing the configuration time.

       I've been using the incubating configuration on demand feature and that has improved our configuration time.

Provide examples of testing the precompiled script plugins using GradleTestKit and separately using ProjectBuilder, show casing pros/cons of each approach.

This is not a problem with the project itself. It may be a Gradle problem. It is probably a Windows 11 vs. Gradle problem.

The build fails with the following error:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':platform'.
> java.util.concurrent.ExecutionException: org.gradle.api.GradleException: Failed to create Jar file C:\Users\feisele\.gradle\caches\jars-9\447ff4e774d837b8b39c9410a295e1b9\base-plugins.jar.

When I look in the C:\Users\feisele\.gradle\caches\jars-9\447ff4e774d837b8b39c9410a295e1b9 folder I see a base-plugins.jar.lock.lock file. Removing this file does not correct the problem. The suffix on that file seems suspicious to me.