anchor.diff:  
   === Virtual vs published platforms
   
  -A platform defined by a component metadata rule for which the `belongsTo` target module isn't published on a repository is called a virtual platform. A virtual platform is considered specially by the engine and participates in dependency resolution like a published module, but triggers dependency version alignment.
  -On the other hand, we can find "real" platforms published on public repositories. Typical examples include BOMs, like the Spring BOM. They differ in the sense that a published platform may refer to modules which are effectively different things. For example the Spring BOM declares dependencies on Spring as well as Apache Groovy. Obviously those things are versioned differently, so it doesn't make sense to align in this case. In other words, if a platform is _published_, Gradle trusts its metadata, and will not try to align dependency versions of this platform.
  +A platform defined by a component metadata rule for which the `belongsTo` target module isn't published on a repository is called a virtual platform.
  +A virtual platform is considered specially by the engine and participates in dependency resolution like a published module, but triggers dependency version alignment.
  +On the other hand, we can find "real" platforms published on public repositories. Typical examples include BOMs, like the Spring BOM. They differ in the sense that a published platform may refer to modules which are effectively different things.
  +For example the Spring BOM declares dependencies on Spring as well as Apache Groovy. Obviously those things are versioned differently, so it doesn't make sense to align in this case. In other words, if a platform is _published_, Gradle trusts its metadata, and will not try to align dependency versions of this platform.
   
   [NOTE]
   ====
  
positive.code: 
  [[sec:version_alignment]]
  == Dependency version alignment
  === Handling inconsistent module versions
  Gradle supports aligning versions of modules which belong to the same "platform". It is often preferable, for example, that the API and implementation modules of a component are using the same version. However, because of the game of transitive dependency resolution, it is possible that different modules belonging to the same platform end up using different versions.
  For example, your project may depend on the `jackson-databind` and `vert.x` libraries, as illustrated below:
  
  .A dependency on the Jackson library
  ====
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/dependencyAlignment/groovy",files="build.gradle[tags=dependencies]"]
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/dependencyAlignment/kotlin",files="build.gradle.kts[tags=dependencies]"]
  
negative.code: 
  However often BOMs are not only providing versions as recommendations, but also a way to override any over version found in the graph. You can enable this behavior by using the `enforcedPlatform` keyword, instead of `platform`, when importing the BOM:
  
  .Importing a BOM, making sure the versions it defines override any other version found
  ====
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/constraintsFromBOM/groovy",files="build.gradle[tags=dependency-on-bom]"]
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/constraintsFromBOM/kotlin",files="build.gradle.kts[tags=dependency-on-bom]"]
  