Docs need attention for Protobuf in v2.3.1

[michael-read]

Is your feature request related to a problem? Please describe.
It's not documented that if you're using Protobuf (instead of Avro), the required dependencies are no longer automatically included in the build for cloudflow-proto, or Akka gRPC Plugin...

Is your feature request related to a specific runtime of Cloudflow or applicable for all runtimes?
2.3.1

Describe the solution you'd like
Documentation should include the need for the following changes:

1. to project/plugins.sbt

addSbtPlugin("com.lightbend.akka.grpc" % "sbt-akka-grpc" % "2.1.3") 

Note: version 2.1.4 seems to cause a conflict with Cloudflow, whereas 2.1.3 seems to work.

3. to build.sbt:

lazy val cloudFlowVersion = "2.3.1"
...
enablePlugins(AkkaGrpcPlugin)
...
    libraryDependencies ++= {
      "com.lightbend.cloudflow" %% "cloudflow-proto"          % cloudFlowVersion,
    }

[thomasschoeftner]

This is the same for avro-support - this now requires:

"com.lightbend.cloudflow" %% "cloudflow-avro" % cloudflowVersion

-> Docs probably also need to be updated for use with AVRO.

I think that change was introduced with Cloudflow 2.3.0 as part of this change by @RayRoestenburg .
On the bright side, this reduces dependencies implicitly introduced by the Cloudflow-sbt plugins which required manual effort to deactivate or re-configure them (e.g. avro-plugins)...

[thomasschoeftner]

@michael-read I propose this doc update: #1240
Is this good enough?

[michael-read]

Looks good to me. TBH, I wasn't aware of the two plugin variables, Cloudflow.library.CloudflowAvro and Cloudflow.library.CloudflowProto. I suppose it would be okay, to just refer to those instead of calling out the specific dependency since you have to specify the version #. I'll defer to @franciscolopezsancho tho.

[thomasschoeftner]

suppose it would be okay, to just refer to those instead of calling out the specific dependency since you have to specify the version

I figured, mentioning the fully qualified library dependency would make sense if somebody was not using SBT, but Maven or Gradle. In that instance, the sbt-plugin and the predfined dependency declaration variables would not be available to the user.

[michael-read]

Ah... makes sense. What's Maven again? ;~)