anchor.diff:  <1> That it is of type `groovy-gradle-plugin` or `kotlin-dsl` to allow convention plugins written in the corresponding DSL
   <2> It depends on our own `plugins-platform` from the `platforms` component
   <3> It depends on the `commons` project from `build-logic` to have access to our own commons convention plugin
  -<4> It depends on the Spring Boot Gradle plugin from the Gradle Plugin Portal so that we may apply it
  +<4> It depends on the Spring Boot Gradle plugin from the Gradle Plugin Portal so that we may apply that plugin to our Spring Boot projects
   
   Now, we can write the convention plugin for Spring application like this:
   
  
positive.code:    They might include minimal project-specific configuration, but these should be kept as minimal as possible.
     This also makes builds less dependent on Gradle's DSLs: If you put your build logic into convention plugins, you can write it directly in Java if you like.
  2. _Isolate cross-cutting technical concerns into project types._
     Technical motivated build configuration is often cross-cutting the software architecture.
     If a project is a "Java Library" or "Kotlin Library" may be totally independent of where it is located in the hierarchy of your components.
     Using convention plugins, allows you to isolate the definition of such project types in a central place, while still reusing them wherever needed.
     (This is a huge advantage over so called <<sharing_build_logic_between_subprojects.adoc#sec:convention_plugins_vs_cross_configuration,cross project configuration>>, which has been popular with older Gradle versions, but is bound to the hierarchy of your project.)
  3. _Declare the origins of components in a central place._
     In this structure, the places where a build can find other components, independent of whether they are <<declaring_repositories.adoc#sub:centralized-repository-declaration,located in a binary repository>> or are <<composite_builds.adoc#settings_defined_composite,available locally as other Gradle builds>>, are defined centrally in the `settings.gradle(.kts)` file.
  
negative.code: 
  Initially, `release/build.gradle(.kts)` is empty.
  The project is of no specific type and does not offer any useful content.
  If we add more files to the `domain-model/release` folder now, for example Java source files, Gradle won't know what to do with these files and will just ignore them.
  We need to assign a type to the project to make Gradle aware of the purpose of such files.
  
  In Gradle, you assign a type to a project by <<plugins.adoc#plugins,applying a plugin>>.
  The simplest thing you can do is to apply one of Gradle's core plugins, like `base` or `java-library`.
  
  However, usually you have additional configuration to do in the context of the product you are building.
  For example, if your project should be a "Java Library", it would not only apply the `java-library` plugin but also configure details such as setting the Java version to 11.
  