anchor.diff:  If you apply other JVM language plugins on top, like `groovy`, `scala` or `org.jetbrains.kotlin.jvm`, you can also write the plugin class in the corresponding language.
   
   In our sample, we choose the option of using Gradle's DSLs for the convention plugins.
  -The `build-logic` component has several projects where each of them defines a project type through a convention plugin –
  +The `build-logic` component has several projects that each define a project type through a convention plugin - one of:
   `java-library`, `kotlin-library`, `spring-application`, `android-application`.
   Also, there is a project called `commons` for build configuration shared by all our project types.
   
  
positive.code: include::sample[dir="samples/build-organization/structuring-software-projects/kotlin",files="server-application/settings.gradle.kts"]
  ====
  
  We see that the `settings.gradle(.kts)` file only defines location for build logic components, other production code components and the inner structue of the component.
  Only the `build.gradle(.kts)` file in the `app` project then defines actual dependencies by applying a convention plugin and utilizing the _dependencies_ block.
  
  .Configuring type and dependencies of the `app` project inside the `server-application` component
  
negative.code: 
  == Defining an inner structure for components
  
  Before we get to the topic of connecting the components, let's first look at them individually.
  
  So far, each component is just an empty folder with an empty `settings.gradle(.kts)` file indicating that this is a component Gradle can work with in some form.
  To fill the component with content, you should define at least one project (referred to as subproject in Gradle's DSLs) in it.
  