anchor.diff:  ----
   <1> Produce a `ServiceStartBuildItem` to indicate that this is a service starting step that needs to run before the `StartupEvent` is sent.
   
  -=== Register Resources for Use in Native Image
  +==== Register Resources for Use in Native Image
   Not all configuration or resources can be consumed at build time. If you have classpath resources that the runtime needs to access, you need to inform the build phase that these resources need to be copied into the native image. This is done by producing one or more `SubstrateResourceBuildItem` or `SubstrateResourceBundleBuildItem` in the case of resource bundles. Examples of this are shown in this sample `registerNativeImageReources` build step:
   
   .Registering Resources and ResourceBundles
  
positive.code: quarkus.log.file.path=/tmp/debug.log
  ----
  
  == Bytecode Recording
  
  One of the main outputs of the build process is recorded bytecode. This bytecode actually sets up the runtime environment. For example, in order to start Undertow, the resulting application will have some bytecode that directly registers all
  Servlet instances and then starts Undertow.
  
negative.code: 
  TODO: config integration
  
  === CDI Extension Points
  As a CDI based runtime, {project-name} extensions often make CDI beans available as part of the extension behavior. The link:cdi-reference.html[Build Time Extension Points] describes the `BuildItems` you can make use of in your extension build steps to achieve this.
  
  === Testing Extensions
  
  Testing of extensions should be done with the `io.quarkus.test.QuarkusUnitTest` runner. This runner allows
  for Arquillian-style tests that test specific functionalities. It is not intended for testing user applications, as this
  