anchor.diff:                      </sample>
   ++++
   
  -
   [[sec:custom_versioning_scheme]]
   ===== Implement a custom versioning scheme
   
   In some corporate environments, the list of module versions that can be declared in Gradle builds is maintained and audited externally. Dependency resolve rules provide a neat implementation of this pattern:
   
  -* In the build script, the developer declares dependencies with the module group and name, but uses a placeholder version, for example: '`default`'.
  +* In the build script, the developer declares dependencies with the module group and name, but uses a placeholder version, for example: `'default'`.
   * The 'default' version is resolved to a specific version via a dependency resolve rule, which looks up the version in a corporate catalog of approved modules.
  - This rule implementation can be neatly encapsulated in a corporate plugin, and shared across all builds within the organisation.
  +
  +This rule implementation can be neatly encapsulated in a corporate plugin, and shared across all builds within the organisation.
   ++++
   <sample id="custom-versioning-scheme" dir="userguide/artifacts/resolutionStrategy" title="Using a custom versioning scheme">
                           <sourcefile file="build.gradle" snippet="custom-versioning-scheme"/>
                       </sample>
   ++++
   
  -
   [[sec:blacklisting_version]]
   ===== Blacklisting a particular version with a replacement
   
  
positive.code:                         <sourcefile file="build.gradle" snippet="artifact-only"/>
                      </sample>
  ++++
   An artifact only notation creates a module dependency which downloads only the artifact file with the specified extension. Existing module descriptors are ignored.
  
  [[sub:classifiers]]
  ===== Classifiers
  
negative.code: 
  There is another way to deal with transitive dependencies _without_ XML descriptor files. You can do this with Gradle, but we don't recommend it. We mention it for the sake of completeness and comparison with other build tools.
  
  The trick is to use only artifact dependencies and group them in lists. This will directly express your first level dependencies and your transitive dependencies (see <<sec:optional_attributes>>). The problem with this is that Gradle dependency management will see this as specifying all dependencies as first level dependencies. The dependency reports won't show your real dependency graph and the `compile` task uses all dependencies, not just the first level dependencies. All in all, your build is less maintainable and reliable than it could be when using client modules, and you don't gain anything.
  