NIFI-6208: Fixes typos in Developers Guide

Signed-off-by: Pierre Villard <pierre.villard.fr@gmail.com>

This closes #3431.

nifi-docs/src/main/asciidoc/developer-guide.adoc

@@ -209,7 +209,7 @@ Expression Language.
 
 [[relationship]]
 ==== Relationship
-Relationships define the routes to which a FlowFile may be transfered
+Relationships define the routes to which a FlowFile may be transferred
 from a Processor. Relationships
 are created by instantiating an instance of the `Relationship.Builder`
 class, calling the appropriate methods
@@ -433,7 +433,7 @@ be taken to ensure that the Processor is thread-safe!
 === Component Lifecycle
 
 The NiFi API provides lifecycle support through use of Java
-Annotations. The `org.apache.nifi.annotations.lifecycle` package
+Annotations. The `org.apache.nifi.annotation.lifecycle` package
 contains
 several annotations for lifecycle management. The following
 Annotations may be applied to Java methods in a NiFi component to
@@ -567,7 +567,7 @@ relied upon for critical business logic.
 === Component Notification
 
 The NiFi API provides notification support through use of Java
-Annotations. The `org.apache.nifi.annotations.notification` package
+Annotations. The `org.apache.nifi.annotation.notification` package
 contains several annotations for notification management. The following
 annotations may be applied to Java methods in a NiFi component to
 indicate to the framework when the methods should be called. For the
@@ -644,7 +644,7 @@ State is stored using the StateManager's `getState`, `setState`, `replace`, and
 require that a Scope be provided. It should be noted that the state that is stored with the Local scope is entirely different
 than state stored with a Cluster scope. If a Processor stores a value with the key of _My Key_ using the `Scope.CLUSTER` scope,
 and then attempts to retrieve the value using the `Scope.LOCAL` scope, the value retrieved will be `null` (unless a value was
-also stored with the same key using the `Scope.CLUSTER` scope). Each Processor's state, is stored in isolation from other
+also stored with the same key using the `Scope.CLUSTER` scope). Each Processor's state is stored in isolation from other
 Processors' state.
 
 It follows, then, that two Processors cannot share the same state. There are, however, some circumstances in which it is very
@@ -782,7 +782,7 @@ public static final Relationship MY_RELATIONSHIP = new Relationship.Builder()
 
 === Documenting Capability and Keywords
 
-The `org.apache.nifi.annotations.documentation` package provides Java
+The `org.apache.nifi.annotation.documentation` package provides Java
 annotations that can be used to document components. The
 CapabilityDescription
 annotation can be added to a Processor, Reporting Task, or Controller
@@ -1111,7 +1111,7 @@ The Processor then emits a Provenance ROUTE event indicating which
 Relationship to which the Processor routed the FlowFile.
 
 This Processor is annotated with the `@SideEffectFree` and
-`@SupportsBatching` annotations from the `org.apache.nifi.annotations.behavior`
+`@SupportsBatching` annotations from the `org.apache.nifi.annotation.behavior`
 package.
 
 
@@ -1188,7 +1188,7 @@ emitted for each FlowFile. This is logged, and the method returns.
 
 This Processor is annotated with the `@SideEffectFree` and
 `@SupportsBatching` annotations from the
-`org.apache.nifi.annotations.behavior`
+`org.apache.nifi.annotation.behavior`
 package.
 
 
@@ -1639,8 +1639,8 @@ by calling the `rollback()` or `rollback(boolean)` method. If using the latter,
 FlowFiles that have been pulled from queues (via the ProcessSession `get` methods) should be penalized before being added
 back to their queues.
 
-When `rollback` is called, any modification that has occurred to the FlowFiles in that session are discarded, to included
-both content modification and attribute modification. Additionally, all Provenance Events are rolled back (with the exception
+When `rollback` is called, any modification that has occurred to the FlowFiles in that session are discarded, this includes
+both content and attribute modifications. Additionally, all Provenance Events are rolled back (with the exception
 of any SEND event that was emitted by passing a value of `true` for the `force` argument). The FlowFiles that were pulled from
 the input queues are then transferred back to the input queues (and optionally penalized) so that they can be processed again.
 
@@ -1649,10 +1649,10 @@ any Provenance Events that occurred are persisted in the Provenance Repository.
 another FlowFile references the same piece of content), and the FlowFiles are transferred to the outbound queues so that the
 next Processors can operate on the data.
 
-It is also important to note how this behavior is affected by using the `org.apache.nifi.annotations.behavior.SupportsBatching`
-annotation. If a Processor utilizes this annotation, calls to `ProcessSession.commit` may not take affect immediately. Rather,
+It is also important to note how this behavior is affected by using the `org.apache.nifi.annotation.behavior.SupportsBatching`
+annotation. If a Processor utilizes this annotation, calls to `ProcessSession.commit` may not take effect immediately. Rather,
 these commits may be batched together in order to provide higher throughput. However, if at any point, the Processor rolls back
-the ProcessSession, all changes since the last call to `commit` will be discarded and all "batched" commits will take affect.
+the ProcessSession, all changes since the last call to `commit` will be discarded and all "batched" commits will take effect.
 These "batched" commits are not rolled back.
 
 
@@ -1671,7 +1671,7 @@ important knowledge about the context that others do not have. Documentation sho
 less familiar with the process are able to use it with ease.
 
 When thinking about the user experience, it is also important to note that consistency is very important. It is best
-to stick with the standard <<naming-convensions>>. This is true for Processor names, Property names and value, Relationship
+to stick with the standard <<naming-conventions>>. This is true for Processor names, Property names and value, Relationship
 names, and any other aspect that the user will experience.
 
 Simplicity is crucial! Avoid adding properties that you don't expect users to understand or change. As developers, we are
@@ -1702,7 +1702,7 @@ it well." Such a Processor should be broken into two separate Processors: one to
 Processor to send data to the remote resource.
 
 
-[[naming-convensions]]
+[[naming-conventions]]
 === 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
@@ -1720,12 +1720,12 @@ is a list of standard conventions that are used:
 
 When creating a Processor, the developer is able to provide hints to the framework about how to utilize the Processor most
 effectively. This is done by applying annotations to the Processor's class. The annotations that can be applied to a
-Processor exist in three sub-packages of `org.apache.nifi.annotations`. Those in the `documentation` sub-package are used
+Processor exist in three sub-packages of `org.apache.nifi.annotation`. Those in the `documentation` sub-package are used
 to provide documentation to the user. Those in the `lifecycle` sub-package instruct the framework which methods should
 be called on the Processor in order to respond to the appropriate life-cycle events. Those in the `behavior` package
 help the framework understand how to interact with the Processor in terms of scheduling and general behavior.
 
-The following annotations from the `org.apache.nifi.annotations.behavior` package can be used to modify how the framework
+The following annotations from the `org.apache.nifi.annotation.behavior` package can be used to modify how the framework
 will handle your Processor:
 
   - `EventDriven`: Instructs the framework that the Processor can be scheduled using the Event-Driven scheduling
@@ -1759,7 +1759,7 @@ will handle your Processor:
 
   - `TriggerWhenAnyDestinationAvailable`: By default, NiFi will not schedule a Processor to run if any of its outbound
     queues is full. This allows back-pressure to be applied all the way a chain of Processors. However, some Processors
-		may need to run even if one of the outbound queues is full. This annotations indicates that the Processor should run
+    may need to run even if one of the outbound queues is full. This annotation indicates that the Processor should run
     if any Relationship is "available." A Relationship is said to be "available" if none of the connections that use
     that Relationship is full. For example, the DistributeLoad Processor makes use of this annotation. If the "round robin"
     scheduling strategy is used, the Processor will not run if any outbound queue is full. However, if the "next available"
@@ -2201,7 +2201,7 @@ invoke any method in the Processor with an `@OnScheduled` annotation, call the P
 and then run the `@OnUnscheduled` and finally `@OnStopped` methods.
 
 If it is desirable to run several iterations of the `onTrigger` method before the other `@OnUnscheduled` and
-`@OnStopped` life-cycle events are triggered, the `run(int)` method can be used to specify now many iterations
+`@OnStopped` life-cycle events are triggered, the `run(int)` method can be used to specify how many iterations
 of `onTrigger` should be called.
 
 There are times when we want to trigger the Processor to run but not trigger the `@OnUnscheduled` and `@OnStopped`
@@ -2438,10 +2438,10 @@ This is done so that any NAR that has a dependency on
 `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
@@ -2493,7 +2493,7 @@ NiFi provides the `@RequiresInstanceClassLoading` annotation to further expand a
 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 it's parent ClassLoader set to the NAR ClassLoader, rather than
+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