Remove blockquotes around lists in the docs

akka-docs/src/main/paradox/java/camel.md

@@ -390,7 +390,6 @@ akka-camel may make some further modifications to it.
 The sample named @extref[Akka Camel Samples with Java](ecs:akka-samples-camel-java) (@extref[source code](samples:akka-sample-camel-java))
 contains 3 samples:
 
->
  * Asynchronous routing and transformation - This example demonstrates how to implement consumer and
 producer actors that support [Asynchronous routing](#camel-asynchronous-routing) with their Camel endpoints.
  * Custom Camel route - Demonstrates the combined usage of a `Producer` and a
@@ -413,4 +412,4 @@ For an introduction to akka-camel 1, see also the [Appendix E - Akka and Camel](
 Other, more advanced external articles (for version 1) are:
 
  * [Akka Consumer Actors: New Features and Best Practices](http://krasserm.blogspot.com/2011/02/akka-consumer-actors-new-features-and.html)
- * [Akka Producer Actors: New Features and Best Practices](http://krasserm.blogspot.com/2011/02/akka-producer-actor-new-features-and.html)
+ * [Akka Producer Actors: New Features and Best Practices](http://krasserm.blogspot.com/2011/02/akka-producer-actor-new-features-and.html)

akka-docs/src/main/paradox/java/logging.md

@@ -24,7 +24,6 @@ while in the second case this is not automatically done. The second parameter
 to `Logging.getLogger` is the source of this logging channel.  The source
 object is translated to a String according to the following rules:
 
->
  * if it is an Actor or ActorRef, its path is used
  * in case of a String it is used as is
  * in case of a class an approximation of its simpleName

akka-docs/src/main/paradox/java/routing.md

@@ -319,7 +319,6 @@ There is no Group variant of the BalancingPool.
 A Router that tries to send to the non-suspended child routee with fewest messages in mailbox.
 The selection is done in this order:
 
->
  * pick any idle routee (not processing message) with empty mailbox
  * pick any routee with empty mailbox
  * pick routee with fewest pending messages in mailbox
@@ -784,4 +783,4 @@ It is not allowed to configure the `routerDispatcher` to be a
 `akka.dispatch.BalancingDispatcherConfigurator` since the messages meant
 for the special router actor cannot be processed by any other actor.
 
-@@@
+@@@

akka-docs/src/main/paradox/java/stream/stream-composition.md

@@ -190,7 +190,6 @@ encoded in the provided `RunnableGraph`. To be able to interact with the running
 needs to return a different object that provides the necessary interaction capabilities. In other words, the
 `RunnableGraph` can be seen as a factory, which creates:
 
->
  * a network of running processing entities, inaccessible from the outside
  * a materialized value, optionally providing a controlled interaction capability with the network
 

akka-docs/src/main/paradox/java/stream/stream-customize.md

@@ -314,7 +314,6 @@ by calling `getStageActorRef(receive)` passing in a function that takes a `Pair`
 or `unwatch(ref)` methods. The reference can be also watched by external actors. The current limitations of this
 `ActorRef` are:
 
->
  * they are not location transparent, they cannot be accessed via remoting.
  * they cannot be returned as materialized values.
  * they cannot be accessed from the constructor of the `GraphStageLogic`, but they can be accessed from the

akka-docs/src/main/paradox/java/stream/stream-flows-and-basics.md

@@ -228,7 +228,6 @@ yet will materialize that stage multiple times.
 By default Akka Streams will fuse the stream operators. This means that the processing steps of a flow or
 stream graph can be executed within the same Actor and has two consequences:
 
->
  * passing elements from one processing stage to the next is a lot faster between fused
 stages due to avoiding the asynchronous messaging overhead
  * fused stream processing stages does not run in parallel to each other, meaning that

akka-docs/src/main/paradox/java/stream/stream-graphs.md

@@ -22,20 +22,18 @@ Akka Streams currently provide these junctions (for a detailed list see @ref:[st
 
  * **Fan-out**
 
->
- * `Broadcast<T>` – *(1 input, N outputs)* given an input element emits to each output
- * `Balance<T>` – *(1 input, N outputs)* given an input element emits to one of its output ports
- * `UnzipWith<In,A,B,...>` – *(1 input, N outputs)* takes a function of 1 input that given a value for each input emits N output elements (where N <= 20)
- * `UnZip<A,B>` – *(1 input, 2 outputs)* splits a stream of `Pair<A,B>` tuples into two streams, one of type `A` and one of type `B`
+    * `Broadcast<T>` – *(1 input, N outputs)* given an input element emits to each output
+    * `Balance<T>` – *(1 input, N outputs)* given an input element emits to one of its output ports
+    * `UnzipWith<In,A,B,...>` – *(1 input, N outputs)* takes a function of 1 input that given a value for each input emits N output elements (where N <= 20)
+    * `UnZip<A,B>` – *(1 input, 2 outputs)* splits a stream of `Pair<A,B>` tuples into two streams, one of type `A` and one of type `B`
 
  * **Fan-in**
 
->
- * `Merge<In>` – *(N inputs , 1 output)* picks randomly from inputs pushing them one by one to its output
- * `MergePreferred<In>` – like `Merge` but if elements are available on `preferred` port, it picks from it, otherwise randomly from `others`
- * `ZipWith<A,B,...,Out>` – *(N inputs, 1 output)* which takes a function of N inputs that given a value for each input emits 1 output element
- * `Zip<A,B>` – *(2 inputs, 1 output)* is a `ZipWith` specialised to zipping input streams of `A` and `B` into a `Pair(A,B)` tuple stream
- * `Concat<A>` – *(2 inputs, 1 output)* concatenates two streams (first consume one, then the second one)
+    * `Merge<In>` – *(N inputs , 1 output)* picks randomly from inputs pushing them one by one to its output
+    * `MergePreferred<In>` – like `Merge` but if elements are available on `preferred` port, it picks from it, otherwise randomly from `others`
+    * `ZipWith<A,B,...,Out>` – *(N inputs, 1 output)* which takes a function of N inputs that given a value for each input emits 1 output element
+    * `Zip<A,B>` – *(2 inputs, 1 output)* is a `ZipWith` specialised to zipping input streams of `A` and `B` into a `Pair(A,B)` tuple stream
+    * `Concat<A>` – *(2 inputs, 1 output)* concatenates two streams (first consume one, then the second one)
 
 One of the goals of the GraphDSL DSL is to look similar to how one would draw a graph on a whiteboard, so that it is
 simple to translate a design from whiteboard to code and be able to relate those two. Let's illustrate this by translating
@@ -300,4 +298,4 @@ arc that injects a single element using `Source.single`.
 @@snip [GraphCyclesDocTest.java]($code$/java/jdocs/stream/GraphCyclesDocTest.java) { #zipping-live }
 
 When we run the above example we see that processing starts and never stops. The important takeaway from this example
-is that balanced cycles often need an initial "kick-off" element to be injected into the cycle.
+is that balanced cycles often need an initial "kick-off" element to be injected into the cycle.

akka-docs/src/main/paradox/java/stream/stream-parallelism.md

@@ -28,7 +28,6 @@ This is how this setup would look like implemented as a stream:
 The two `map` stages in sequence (encapsulated in the "frying pan" flows) will be executed in a pipelined way,
 basically doing the same as Roland with his frying pans:
 
->
  1. A `ScoopOfBatter` enters `fryingPan1`
  2. `fryingPan1` emits a HalfCookedPancake once `fryingPan2` becomes available
  3. `fryingPan2` takes the HalfCookedPancake
@@ -87,7 +86,6 @@ in sequence.
 
 It is also possible to organize parallelized stages into pipelines. This would mean employing four chefs:
 
->
  * the first two chefs prepare half-cooked pancakes from batter, in parallel, then putting those on a large enough
 flat surface.
  * the second two chefs take these and fry their other side in their own pans, then they put the pancakes on a shared

akka-docs/src/main/paradox/java/testing.md

@@ -8,7 +8,6 @@ perform tests.
 Akka comes with a dedicated module `akka-testkit` for supporting tests at
 different levels, which fall into two clearly distinct categories:
 
->
  * Testing isolated pieces of code without involving the actor model, meaning
 without multiple threads; this implies completely deterministic behavior
 concerning the ordering of events and no concurrency concerns and will be
@@ -130,7 +129,6 @@ underlying actor:
 You may of course mix and match both modi operandi of `TestActorRef` as
 suits your test needs:
 
->
  * one common use case is setting up the actor into a specific internal state
 before sending the test message
  * another is to verify correct internal state transitions after having sent
@@ -190,7 +188,6 @@ out, in which case they use the default value from configuration item
 `akka.test.single-expect-default` which itself defaults to 3 seconds (or they
 obey the innermost enclosing `Within` as detailed [below](#testkit-within)). The full signatures are:
 
->
  * 
    `public <T> T expectMsgEquals(FiniteDuration max, T msg)`
    The given message object must be received within the specified time; the
@@ -632,7 +629,6 @@ send returns and no `InterruptedException` will be thrown.
 To summarize, these are the features with the `CallingThreadDispatcher`
 has to offer:
 
->
  * Deterministic execution of single-threaded tests while retaining nearly full
 actor semantics
  * Full message processing history leading up to the point of failure in
@@ -682,4 +678,4 @@ akka {
 ## Configuration
 
 There are several configuration properties for the TestKit module, please refer
-to the @ref:[reference configuration](general/configuration.md#config-akka-testkit).
+to the @ref:[reference configuration](general/configuration.md#config-akka-testkit).

akka-docs/src/main/paradox/java/typed-actors.md

@@ -89,7 +89,6 @@ and we know how to create a Typed Actor from that, so let's look at calling thes
 
 Methods returning:
 
->
  * `void` will be dispatched with `fire-and-forget` semantics, exactly like `ActorRef.tell`
  * `scala.concurrent.Future<?>` will use `send-request-reply` semantics, exactly like `ActorRef.ask`
  * `akka.japi.Option<?>` will use `send-request-reply` semantics, but *will* block to wait for an answer,
@@ -175,7 +174,6 @@ e.g. when interfacing with untyped actors.
 
 By having your Typed Actor implementation class implement any and all of the following:
 
->
  * `TypedActor.PreStart`
  * `TypedActor.PostStop`
  * `TypedActor.PreRestart`
@@ -208,4 +206,4 @@ In order to round robin among a few instances of such actors, you can simply cre
 and then facade it with a `TypedActor` like shown in the example below. This works because typed actors of course
 communicate using the same mechanisms as normal actors, and methods calls on them get transformed into message sends of `MethodCall` messages.
 
-@@snip [TypedActorDocTest.java]($code$/java/jdocs/actor/TypedActorDocTest.java) { #typed-router }
+@@snip [TypedActorDocTest.java]($code$/java/jdocs/actor/TypedActorDocTest.java) { #typed-router }