anchor.diff:  [WARNING]
   ====
   Declaring a `dependencies.toml` file doesn't make it the single source of truth for dependencies: it's a conventional location where dependencies can be declared.
  -As soon as you start using catalogs it's strongly recommended to declare all your dependencies in a catalog and not hardcode group/artifact/version strings in build scripts.
  -But be aware that it's likely that some plugins add dependencies transparently, therefore dependencies defined outside of this file.
  -
  -Just like `src/main/java` is a convention to find the Java sources which doesn't prevent additional source directories to be declared (either in a build script or a plugin), the presence of the `dependencies.toml` file doesn't mean that it's impossible to declare dependencies elsewhere.
  +As soon as you start using catalogs, it's strongly recommended to declare all your dependencies in a catalog and not hardcode group/artifact/version strings in build scripts.
  +Be aware that it may happen that plugins add dependencies, which are dependencies defined outside of this file.
  +
  +Just like `src/main/java` is a convention to find the Java sources, which doesn't prevent additional source directories to be declared (either in a build script or a plugin), the presence of the `dependencies.toml` file doesn't prevent the declaration of dependencies elsewhere.
   
   The presence of this file does, however, suggest that most dependencies, if not all, will be declared in this file.
   Therefore, updating a dependency version, for most users, should only consists of changing a line in this file.
  
positive.code: [[sub:version-catalog]]
  === Using a version catalog
  
  A _version catalog_ is a list of dependencies, represented as dependency coordinates only, that a user can pick from when declaring dependencies in a build script.
  
  For example, instead of declaring a dependency using a string notation, the dependency coordinates can be picked from a _version catalog_:
  
  
negative.code: 
  In this context, `libs` is a catalog and `groovy` represents a dependency available in this catalog. A version catalog provides a number of advantages over declaring the dependencies directly in build scripts:
  
  - For each catalog, Gradle generates _type-safe accessors_ so that you can easily add dependencies with autocompletion in the IDE.
  - Each catalog is visible to all projects of a build. It is a central place to declare a version of a dependency and to make sure that a change to that version applies to every subproject.
  - Catalogs can declare <<platforms.adoc#sec:dependency-bundles, dependency bundles>>, which are "groups of dependencies" that are commonly used together.
  - Catalogs can separate the group and name of a dependency from its actual version and use <<platforms.adoc#sec:common-version-numbers, version references>> instead, making it possible to share a version declaration between multiple dependencies.
  
  Adding a dependency using the `libs.someLib` notation works exactly like if you had hardcoded the group, artifact and version directly in the build script.
  
  WARNING: A dependency catalog doesn't enforce the version of a dependency: like a regular dependency notation, it declares the requested version or a <<rich_versions.adoc#rich-version-constraints,rich version>>. That version is not necessarily the version that is selected during <<dependency_resolution#,conflict resolution>>. 
  
  [[sub:version-catalog-declaration]]
  === Declaring a version catalog
  