anchor.diff:  Basically, this is the part of the build that is not required on local development machines.
   
   [NOTE]
  -The domain of our example is to get informed about link:https://gradle.org/releases/[Gradle Build Tool releases].
  +The domain of our example is to build a tool to inform people about link:https://gradle.org/releases/[Gradle Build Tool releases].
   Concretely, the application lists Gradle releases with links to release notes (_user_ feature) and
   offers an administration interface for the range of releases to be listed (_admin_ feature).
   
  
positive.code:    Note that <<structuring_software_products_details.adoc#settings_convention_plugins,there are different strategies to avoid duplicating this information>> in each `settings.gradle(.kts)` of each of your components.
  4. _Declare platforms in a central place._
     Having a platform component as in the example is optional.
     You could do things without, e.g. by declaring <<dependency_constraints.adoc#dependency-constraints,dependency constraints>> directly in your convention plugins.
     However, <<platforms.adoc#sec:sharing-dep-versions-between-projects,platforms>> are a good option to have all the boundaries for the environment in which your software operates defined in a central place.
  
negative.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._
     Technically motivated build configuration often cuts across the entire software architecture.
     Whether or not a project is a "Java Library" or "Kotlin Library" may be totally independent of where it is located in the hierarchy of your components.
     If you use convention plugins, this 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.
  