anchor.diff:  `my-controller-service-api-nar` will also be able to access
   all of the Controller Services that are provided by the
   `nifi-standard-services-api-nar`, such as the SSLContextService.
  -In this same vane, it is not necessary to create a different
  +In this same vein, it is not necessary to create a different
   "service-api" NAR for each service. Instead, it often
   makes sense to have a single "service-api" NAR that encapsulates the
  -API's for many different Controller Services,
  +APIs for many different Controller Services,
   as is done by the `nifi-standard-services-api-nar`. Generally, the API
   will not include extensive dependencies, and as a result,
   ClassLoader isolation may be less important, so lumping together many
  
positive.code: Taking this approach of formatting the data for a particular endpoint and then sending the data to that endpoint within the same Processor
  has several drawbacks:
  
  	- The Processor becomes very complex, as it has to perform the data translation task as well as the task of
  	  sending the data to the remote service.
  	- If the Processor is unable to communicate with the remote service, it will route the data to a `failure` Relationship. In this case,
  	  the Processor will be responsible to perform the data translation again. And if it fails again, the translation is done yet again.
  	- If we have five different Processors that translate the incoming data into this new format before sending the data, we have a great
  	  deal of duplicated code. If the schema changes, for instance, many Processors must be updated.
  	- This intermediate data is thrown away when the Processor finishes sending to the remote service. The intermediate data format
  	  may well be useful to other Processors.
  
  In order to avoid these issues, and make Processors more reusable, a Processor should always stick to the principal of "do one thing and do
  it well." Such a Processor should be broken into two separate Processors: one to convert the data from Format X to Format Y, and another
  Processor to send data to the remote resource.
  
  
  [[naming-convensions]]
  === Naming Conventions
  
  In order to deliver a consistent look and feel to users, it is advisable that Processors keep with standard naming conventions. The following
  is a list of standard conventions that are used:
  
  	- Processors that pull data from a remote system are named Get<Service> or Get<Protocol>, depending on if they poll data from arbitrary
  	  sources over a known Protocol (such as GetHTTP or GetFTP) or if they pull data from a known service (such as GetKafka)
  	- Processors that push data to a remote system are named Put<Service> or Put<Protocol>.
  	- Relationship names are lower-cased and use spaces to delineated words.
  	- Property names capitalize significant words, as would be done with the title of a book.
  
  
  
  
negative.code: available on a component’s classpath. You can annotate a component with `@RequiresInstanceClassLoading`
  to indicate that the instance ClassLoader for the component requires a copy of all the resources in the
  component's NAR ClassLoader. When `@RequiresInstanceClassLoading` is not present, the
  instance ClassLoader simply has its parent ClassLoader set to the NAR ClassLoader, rather than
  copying resources.
  
  The `@RequiresInstanceClassLoading` annotation also provides an optional flag `cloneAncestorResources'. If
  