anchor.diff:  
   [discrete]
   ==== Option 1: Driver Resolver
  -WebDriverManager CLI can be used to resolve drivers (e.g., chromedriver, geckodriver) using the usual <<resolution-algorithm,resolution algorithm>>, but executed directly from the shell. This feature can be interesting if we want to download drivers outside a Java program. To use this option, we need to invoke WebDriverManager CLI using the following arguments (supposing we need to resolve chromedriver):
  +WebDriverManager CLI can be used to resolve drivers (e.g., chromedriver, geckodriver) applying the usual <<resolution-algorithm,resolution algorithm>> from the shell. This feature can be interesting if we want to download drivers outside a Java program. To use this option, we need to invoke WebDriverManager CLI using the following arguments (supposing we need to resolve chromedriver):
   
   * Fat-JAR:
   [source,shell]
  
positive.code: ----
  
  === WDM Agent
  WebDriverManager can also be used as _Java Agent_. In other words, using the JVM instrumentation API, WebDriverManager can intercept applications running on the JVM and modify their bytecode. The WebDriverManager Agent uses this approach to check the objects being created in the JVM. Before Selenium WebDriver objects are instantiated (`ChromeDriver`, `FirefoxDriver`, etc.), the required manager is used to resolve its driver (chromedriver, geckodriver, etc.). Thanks to this approach, we can get rid of the WebDriverManager call (e.g. `WebDriverManager.chromedriver.setup()`) from our test, for example:
  
  [source,java]
  ----
  
negative.code: ----
  mvn exec:java -Dexec.args="<args>"
  ----
  3. Using the WebDriverManager Docker container. Each new release of WebDriverManager is pushed to https://hub.docker.com/r/bonigarcia/webdrivermanager[Docker Hub] as a container based on https://hub.docker.com/_/openjdk[OpenJDK] plus the WebDriverManager fat-JAR. The default command to run the WebDriverManager Docker container is described below.        
  +
  [source,shell]
  ----
  