anchor.diff:  == Testing Extensions
   
   Testing of extensions should be done with the `org.jboss.shamrock.test.ShamrockUnitTest` runner. This runner allows
  -for Arquillian-style tests that test specific functionalities. It is not intended for testing user applications, this
  +for Arquillian-style tests that test specific functionalities. It is not intended for testing user applications, as this
   should be done via `org.jboss.shamrock.test.ShamrockTest`. The main difference between these test runners is that
   `ShamrockTest` simply boots the application once at the start of the run, while `ShamrockUnitTest` deploys a custom
   Shamrock application for each test class.
   
  -These tests should be placed in the augmentation module, if additional Shamrock modules are required for testing
  -their augment modules should also be added as test scoped dependencies.
  +These tests should be placed in the deployment module, if additional Shamrock modules are required for testing
  +their deployment modules should also be added as test scoped dependencies.
   
   An example test class may look like:
   
  
positive.code: = Extension Authors Guide
  
  Shamrock extensions consist of two distinct parts, augmentation and runtime. The augmentation part is responsible for
  all metadata processing, such as reading annotation, XML descriptors etc. The output of this augmentation phase
  is recorded bytecode which is responsible for directly instantiating the relevant runtime services.
  
  This means that metadata is only processed once at build time, which both saves on startup time, but also on memory
  usage as the classes etc that are used for processing are not loaded (or even present) in the runtime JVM.
  
  == Three Phases of Bootstrap and Shamrock Philosophy
  
  There are three distinct phases of the bootstrap of a Shamrock app:
  
  Augmentation::
      This is the first phase, and is done by the build step processors. These processors have access to Jandex annotation
      information and can parse any descriptors, but should not attempt to load any application classes. The output of these
      build steps is some recorded bytecode, that is used to actually bootstrap the application at runtime. Depending on the mode
      this step may be run in a different JVM to the following two steps.
  
  Static Init::
      If bytecode is recorded with `@Record(STATIC_INIT)` then it will be executed from a static init method on the main
      class. This means that for a native image build this code is executed in a normal JVM as part of the image build
      process. Any retained objects that are produced in this stage will be directly serialized into the native image.
      This means that if a framework can boot in this phase then it will have its booted state directly written to the
      image, so the boot code does not need to be executed when the image is started.
  +
  There are some restrictions on what can be done in this stage as Substrate disallows some objects in the native image,
  for example you should not attempt to listen on a port or start threads in this phase.
  +
  In JVM mode there is no real difference between this and runtime init, except that this is always executed first.
  
  Runtime Init::
      If bytecode is recorded with `@Record(RUNTIME_INIT)` then it is executed from the application's main method. This code
      will be run on native image boot. In general as little code as possible should be executed in this phase, and should
      be restricted to code that needs to open ports etc.
  
  This means that there are really two different optimizations we are trying to make, for native image we want to boot
  as much as possible in static init, so that the resulting native image will start as fast as possible. When running on
  the JVM we want to push as much code as possible into offline processing, so that as few classes as possible are loaded
  on application start, and so that as little processing as possible is done as part of application startup. In servers like
  WildFly, deployment related classes such as XML parsers hang around for the life of the application, using up valuable
  memory. Shamrock aims to eliminate this, so that the only classes loaded at runtime are actually used at runtime.
  
  As an example, the only reason that a Shamrock application should load an XML parser is if the user is using XML in their
  application. Any XML parsing of configuration should be done in the Augmentation phase.
  
  Another advantage of this approach is that it means Substrate can more easily eliminate features that are not used.
  If features are directly initialized via bytecode, Substrate can detect that a method is never called and eliminate
  that method. If config is read at runtime, Substrate cannot reason about the contents of the config and so needs to
  keep all features in case they are required.
  
  
  == Maven setup
  
  Your runtime artifact should depend on shamrock-core-runtime, and possibly the runtime artifacts of other Shamrock
  modules if you want to use functionality provided by them. You will also need to include the `maven-dependency-plugin`
  
negative.code: === RecorderContext
  
  `org.jboss.shamrock.deployment.recording.RecorderContext` provides some convenience methods to enhance bytecode recording,
  this includes the ability to register creation functions for classes without no-arg constructors, to register an object
  substitution (basically a transformer from a non-serializable object to a serializable one and vice versa), and to create
  a class proxy. This interface can be directly injected as a method parameter into any `@Recorder` method.
  
  