anchor.diff:  The following examples demonstrate this behavior. Please note that the examples do not
   actually do anything realistic. Instead, they mimic common scenarios for testing
   interactions with the database. All methods imported statically from the `Logger` class
  -simply log contextual information in order to help us better understand the execution
  -order of user-supplied callback methods and callback methods in extensions.
  +log contextual information in order to help us better understand the execution order of
  +user-supplied callback methods and callback methods in extensions.
   
   [source,java,indent=0]
   .Extension1
  
positive.code: ===== Enabling Automatic Extension Detection
  
  Auto-detection is an advanced feature and is therefore not enabled by default. To enable
  it, simply set the `junit.jupiter.extensions.autodetection.enabled` _configuration
  parameter_ to `true`. This can be supplied as a JVM system property, as a _configuration
  parameter_ in the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the
  JUnit Platform configuration file (see <<running-tests-config-params>> for details).
  
  For example, to enable auto-detection of extensions, you can start your JVM with the
  following system property.
  
negative.code: 
  Sometimes it can be useful to run a test suite _without_ certain conditions being active.
  For example, you may wish to run tests even if they are annotated with `@Disabled` in
  order to see if they are still _broken_. To do this, provide a pattern for the
  `junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
  conditions should be deactivated (i.e., not evaluated) for the current test run. The
  pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
  