You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pekko.apache.org by fa...@apache.org on 2023/01/25 10:33:07 UTC
[incubator-pekko-grpc] branch main updated: update some akka refs in markdown files (#10)
This is an automated email from the ASF dual-hosted git repository.
fanningpj pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-pekko-grpc.git
The following commit(s) were added to refs/heads/main by this push:
new 59bd6546 update some akka refs in markdown files (#10)
59bd6546 is described below
commit 59bd65462b8a7d5f667a24be2d0d434ddad323c9
Author: PJ Fanning <pj...@users.noreply.github.com>
AuthorDate: Wed Jan 25 10:33:00 2023 +0000
update some akka refs in markdown files (#10)
---
CONTRIBUTING.md | 85 ++++++++++++++++-----------------
README.md | 18 ++++---
benchmark-java/project/build.properties | 2 +-
build.sbt | 2 +-
project/Common.scala | 23 ++++-----
5 files changed, 62 insertions(+), 68 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ada93ea..53c0537d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,14 +1,16 @@
-# Welcome! Thank you for contributing to Akka gRPC!
+# Welcome! Thank you for contributing to Apache Pekko gRPC!
We follow the standard GitHub [fork & pull](https://help.github.com/articles/using-pull-requests/#fork--pull) approach to pull requests. Just fork the official repo, develop in a branch, and submit a PR!
-You're always welcome to submit your PR straight away and start the discussion (without reading the rest of this wonderful doc, or the README.md). The goal of these notes is to make your experience contributing to Akka gRPC as smooth and pleasant as possible. We're happy to guide you through the process once you've submitted your PR.
+You're always welcome to submit your PR straight away and start the discussion (without reading the rest of this wonderful doc, or the README.md). The goal of these notes is to make your experience contributing to Pekko gRPC as smooth and pleasant as possible. We're happy to guide you through the process once you've submitted your PR.
-# The Akka Community
+# The Apache Pekko Community
-In case of questions about the contribution process or for discussion of specific issues please visit the [akka/dev gitter chat](https://gitter.im/akka/dev).
+If you have questions about the contribution process or discuss specific issues, please interact with the community using the following resources.
-You may also check out these [other resources](https://akka.io/get-involved/).
+- [GitHub discussions](https://github.com/apache/incubator-pekko-grpc/discussions): for questions and general discussion.
+- [Pekko dev mailing list](https://lists.apache.org/list.html?dev@pekko.apache.org): for Pekko development discussions.
+- [GitHub issues](https://github.com/apache/incubator-pekko-grpc/issues): for bug reports and feature requests. Please search the existing issues before creating new ones. If you are unsure whether you have found a bug, consider asking in GitHub discussions or the mailing list first.
# Navigating around the project & codebase
@@ -16,20 +18,20 @@ You may also check out these [other resources](https://akka.io/get-involved/).
Depending on which version (or sometimes module) you want to work on, you should target a specific branch as explained below:
-* `main` – active development branch of akka-grpc
+* `main` – active development branch of pekko-grpc
## Issues
In general *all issues are open for anyone working on them*, however if you're new to the project and looking for an issue
that will be accepted and likely is a nice one to get started you should check out the following tags:
-- [help wanted](https://github.com/akka/akka-grpc/labels/help%20wanted) - which identifies issues that the core team will likely not have time to work on, or the issue is a nice entry level ticket. If you're not sure how to solve a ticket but would like to work on it feel free to ask in the issue about clarification or tips.
-- [nice-to-have (low-priority)](https://github.com/akka/akka-grpc/labels/nice-to-have%20%28low-prio%29) - are tasks which make sense, however are not very high priority (in face of other very high priority issues). If you see something interesting in this list, a contribution would be really wonderful!
+- [help wanted](https://github.com/apache/incubator-pekko-grpc/labels/help%20wanted) - which identifies issues that the core team will likely not have time to work on, or the issue is a nice entry level ticket. If you're not sure how to solve a ticket but would like to work on it feel free to ask in the issue about clarification or tips.
+- [nice-to-have (low-priority)](https://github.com/apache/incubator-pekko-grpc/labels/nice-to-have%20%28low-prio%29) - are tasks which make sense, however are not very high priority (in face of other very high priority issues). If you see something interesting in this list, a contribution would be really wonderful!
Another group of special tags indicate specific states a ticket is in:
-- [bug](https://github.com/akka/akka-grpc/labels/bug) - bugs take priority in being fixed above features. The core team dedicates a number of days to working on bugs each sprint. Bugs which have reproducers are also great for community contributions as they're well isolated. Sometimes we're not as lucky to have reproducers though, then a bugfix should also include a test reproducing the original error along with the fix.
-- [failed](https://github.com/akka/akka-grpc/labels/failed) - tickets indicate a Jenkins failure (for example from a nightly build). These tickets usually start with the `FAILED: ...` message, and include a stacktrace + link to the Jenkins failure. The tickets are collected and worked on with priority to keep the build stable and healthy. Often times it may be simple timeout issues (Jenkins boxes are slow), though sometimes real bugs are discovered this way.
+- [bug](https://github.com/apache/incubator-pekko-grpc/labels/bug) - bugs take priority in being fixed above features. The core team dedicates a number of days to working on bugs each sprint. Bugs which have reproducers are also great for community contributions as they're well isolated. Sometimes we're not as lucky to have reproducers though, then a bugfix should also include a test reproducing the original error along with the fix.
+- [failed](https://github.com/apache/incubator-pekko-grpc/labels/failed) - tickets indicate a Jenkins failure (for example from a nightly build). These tickets usually start with the `FAILED: ...` message, and include a stacktrace + link to the Jenkins failure. The tickets are collected and worked on with priority to keep the build stable and healthy. Often times it may be simple timeout issues (Jenkins boxes are slow), though sometimes real bugs are discovered this way.
Pull Request validation states:
@@ -41,32 +43,31 @@ gRPC runs on HTTP/2 and connections commonly use HTTPS.
If you are running on JDK 8, you will need to use at least version 1.8.0u251 to make sure ALPN protocol negotiation is available.
-# Akka gRPC contributing guidelines
+# Pekko gRPC contributing guidelines
-These guidelines apply to all Akka projects, by which we mean both the `akka/akka` repository,
-as well as any plugins or additional repos located under the Akka GitHub organisation, e.g. `akka/akka-grpc` and others.
+These guidelines apply to all Pekko projects, by which we mean both the `apache/incubator-pekko` repository,
+as well as any plugins or additional repos located under the Apache Pekko GitHub organisation, e.g. `apache/incubator-pekko-grpc` and others.
These guidelines are meant to be a living document that should be changed and adapted as needed.
We encourage changes that make it easier to achieve our goals in an efficient way.
Please also note that we have a *Code of Conduct* in place which aims keep our community a nice and helpful one.
-You can read its full text here: [Lightbend Community Code of Conduct](https://www.lightbend.com/conduct).
+You can read its full text here: [ASF Code of Conduct](https://www.apache.org/foundation/policies/conduct).
## General Workflow
The below steps are how to get a patch into a main development branch (e.g. `main`).
The steps are exactly the same for everyone involved in the project (be it core team, or first time contributor).
-1. To avoid duplicated effort, it might be good to check the [issue tracker](https://github.com/akka/akka-grpc/issues) and [existing pull requests](https://github.com/akka/akka-grpc/pulls) for existing work.
- - If there is no ticket yet, feel free to [create one](https://github.com/akka/akka-grpc/issues/new) to discuss the problem and the approach you want to take to solve it.
-1. [Fork the project](https://github.com/akka/akka-grpc#fork-destination-box) on GitHub. You'll need to create a feature-branch for your work on your fork, as this way you'll be able to submit a PullRequest against the mainline Akka-gRPC.
-1. Create a branch on your fork and work on the feature. For example: `git checkout -b wip-custom-headers-akka-grpc`
+1. To avoid duplicated effort, it might be good to check the [issue tracker](https://github.com/apache/incubator-pekko-grpc/issues) and [existing pull requests](https://github.com/apache/incubator-pekko-grpc/pulls) for existing work.
+ - If there is no ticket yet, feel free to [create one](https://github.com/apache/incubator-pekko-grpc/issues/new) to discuss the problem and the approach you want to take to solve it.
+1. [Fork the project](https://github.com/apache/incubator-pekko-grpc#fork-destination-box) on GitHub. You'll need to create a feature-branch for your work on your fork, as this way you'll be able to submit a PullRequest against the mainline Pekko-gRPC.
+1. Create a branch on your fork and work on the feature. For example: `git checkout -b wip-custom-headers-pekko-grpc`
- Please make sure to follow the general quality guidelines (specified below) when developing your patch.
- Please write additional tests covering your feature and adjust existing ones if needed before submitting your Pull Request. The `validatePullRequest` sbt task ([explained below](#the-validatepullrequest-task)) may come in handy to verify your changes are correct.
1. Once your feature is complete, prepare the commit following our [Creating Commits And Writing Commit Messages](#creating-commits-and-writing-commit-messages). For example, a good commit message would be: `Adding compression support for Manifests #22222` (note the reference to the ticket it aimed to resolve).
1. Now it's finally time to [submit the Pull Request](https://help.github.com/articles/using-pull-requests)!
-1. If you have not already done so, you will be asked by our CLA bot to [sign the Lightbend CLA](https://www.lightbend.com/contribute/cla) online CLA stands for Contributor License Agreement and is a way of protecting intellectual property disputes from harming the project.
-1. If you're not already on the contributors white-list, the @akka-ci bot will ask `Can one of the repo owners verify this patch?`, to which a core member will reply by commenting `OK TO TEST`. This is just a sanity check to prevent malicious code from being run on the Jenkins cluster.
+1. For large PRs, we may ask you to submit an Apache Software Foundation [CLA](https://www.apache.org/licenses/contributor-agreements.html).
1. Now both committers and interested people will review your code. This process is to ensure the code we merge is of the best possible quality, and that no silly mistakes slip through. You're expected to follow-up these comments by adding new commits to the same branch. The commit messages of those commits can be more lose, for example: `Removed debugging using printline`, as they all will be squashed into one commit before merging into the main branch.
- The community and team are really nice people, so don't be afraid to ask follow up questions if you didn't understand some comment, or would like to clarify how to continue with a given feature. We're here to help, so feel free to ask and discuss any kind of questions you might have during review!
1. After the review you should fix the issues as needed (pushing a new commit for new review etc.), iterating until the reviewers give their thumbs up–which is signalled usually by a comment saying `LGTM`, which means "Looks Good To Me".
@@ -77,18 +78,18 @@ The steps are exactly the same for everyone involved in the project (be it core
The TL;DR; of the above very precise workflow version is:
-1. Fork akka-grpc
+1. Fork pekko-grpc
2. Hack and test on your feature (on a branch)
3. Submit a PR
4. Sign the CLA if necessary
4. Keep polishing it until received enough LGTM
5. Profit!
-Note that the akka-grpc sbt project is not as large as the Akka one, so `sbt` should be able to run with less heap than with the Akka project. In case you need to increase the heap, this can be specified using a command line argument `sbt -mem 2048` or in the environment variable `SBT_OPTS` but then as a regular JVM memory flag, for example `SBT_OPTS=-Xmx2G`, on some platforms you can also edit the global defaults for sbt in `/usr/local/etc/sbtopts`.
+Note that the pekko-grpc sbt project is not as large as the Pekko one, so `sbt` should be able to run with less heap than with the Pekko project. In case you need to increase the heap, this can be specified using a command line argument `sbt -mem 2048` or in the environment variable `SBT_OPTS` but then as a regular JVM memory flag, for example `SBT_OPTS=-Xmx2G`, on some platforms you can also edit the global defaults for sbt in `/usr/local/etc/sbtopts`.
## Binary compatibility
-Akka gRPC is still in experimental mode, so this section does not apply yet.
+Pekko gRPC is still in experimental mode, so this section does not apply yet.
However, once we declare the project stable, we will adhere to the following
rules:
@@ -96,7 +97,7 @@ Our binary compatibility guarantees are described in depth in the
[Binary Compatibility](https://doc.akka.io/docs/akka-grpc/current/binary-compatibility.html)
section of the documentation.
-Akka gRPC uses [Lightbend MiMa](https://github.com/lightbend/mima) to
+Pekko gRPC uses [Lightbend MiMa](https://github.com/lightbend/mima) to
validate binary compatibility of incoming Pull Requests. If your PR fails due to binary compatibility issues, you may see
an error like this:
@@ -121,12 +122,12 @@ incompatibility has been successfully ignored after adding it to the filter file
### Generated code
-Generated code is not checked by MiMa. However, we do want code generated with a previous version of Akka gRPC
+Generated code is not checked by MiMa. However, we do want code generated with a previous version of Pekko gRPC
to be usable with later versions. This means you should be extra careful not to introduce binary incompatibilities
-when changing the code generators. Of course, when adding new Akka gRPC features it is not required that those
+when changing the code generators. Of course, when adding new Pekko gRPC features it is not required that those
features work with code generated for previous versions.
-Generated code may call Akka gRPC code that is internal. In those cases we mark those internal API's as
+Generated code may call Pekko gRPC code that is internal. In those cases we mark those internal API's as
`@InternalStableApi` to avoid accidentally breaking compatibility.
## Pull Request Requirements
@@ -136,12 +137,12 @@ For a Pull Request to be considered at all it has to meet these requirements:
1. Regardless if the code introduces new features or fixes bugs or regressions, it must have comprehensive tests.
1. The code must be well documented in the Lightbend's standard documentation format (see the ‘Documentation’ section below).
1. The commit messages must properly describe the changes, see further below.
-1. All Lightbend projects must include Lightbend copyright notices. Each project can choose between one of two approaches:
+1. All Apache projects must include Apache copyright notices. Each project can choose between one of two approaches:
- 1. All source files in the project must have a Lightbend copyright notice in the file header.
- 1. The Notices file for the project includes the Lightbend copyright notice and no other files contain copyright notices. See https://www.apache.org/legal/src-headers.html for instructions for managing this approach for copyrights.
+ 1. All source files in the project must have an Apache copyright notice in the file header.
+ 1. The Notices file for the project includes the Apache copyright notice and no other files contain copyright notices. See https://www.apache.org/legal/src-headers.html for instructions for managing this approach for copyrights.
- Akka gRPC uses the first choice, having copyright notices in every file header.
+ Pekko gRPC uses the first choice, having copyright notices in every file header.
### Additional guidelines
@@ -165,7 +166,6 @@ All documentation must abide by the following maxims:
- Example code should be run as part of an automated test suite.
- Version should be **programmatically** specifiable to the build.
- Generation should be **completely automated** and available for scripting.
-- Artifacts that must be included in the Lightbend stack should be published to a maven “documentation” repository as documentation artifacts.
- When renaming Markdown files, add a rewrite rule to the `.htaccess` file to not break external links.
All documentation is preferred to be in Lightbend's standard documentation format [Paradox](https://github.com/lightbend/paradox).
@@ -183,7 +183,7 @@ The rendered documentation will be available under `docs/target/paradox/site/mai
### JavaDoc
-Akka gRPC generates JavaDoc-style API documentation using the [genjavadoc](https://github.com/lightbend/genjavadoc) sbt plugin, since the sources are written mostly in Scala.
+Pekko gRPC generates JavaDoc-style API documentation using the [genjavadoc](https://github.com/lightbend/genjavadoc) sbt plugin, since the sources are written mostly in Scala.
Generating JavaDoc is not enabled by default, as it's not needed on day-to-day development as it's expected to just work.
If you'd like to check if you links and formatting looks good in JavaDoc (and not only in ScalaDoc), you can generate it by running:
@@ -236,7 +236,7 @@ Example:
## Pull request validation workflow details
-Akka gRPC uses [Jenkins GitHub pull request builder plugin](https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin)
+Pekko gRPC uses [Jenkins GitHub pull request builder plugin](https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin)
that automatically merges the code, builds it, runs the tests and comments on the Pull Request in GitHub.
Upon a submission of a Pull Request the GitHub pull request builder plugin will post a following comment:
@@ -245,16 +245,11 @@ Upon a submission of a Pull Request the GitHub pull request builder plugin will
This requires a member from a core team to start Pull Request validation process by posting comment consisting only of `OK TO TEST`. From now on, whenever new commits are pushed to the Pull Request, a validation job will be automatically started and the results of the validation posted to the Pull Request.
-A Pull Request validation job can be started manually by posting `PLS BUILD` comment on the Pull Request.
-
-Note, that `OK TO TEST` will only be picked up when the user asking for it is considered an admin. Public (!) members of the [akka organization](https://github.com/orgs/akka/people) are automatically considered admins and users manually declared admin in the Jenkins job (currently no one is explicitly listed). `PLS BUILD` can be issued by everyone that is an admin or everyone who was whitelisted in the Jenkins Job (whitelisting != declaring someone an admin).
-
-
## Source style
### Scala style
-Akka gRPC uses [Scalariform](https://github.com/daniel-trinh/scalariform) to enforce some of the code style rules.
+Pekko gRPC uses [Scalariform](https://github.com/daniel-trinh/scalariform) to enforce some of the code style rules.
### Java style
@@ -269,7 +264,7 @@ Thus we ask Java contributions to follow these simple guidelines:
Avoid short test timeouts, since Jenkins server may GC heavily causing spurious test failures. GC pause or other hiccup of 2 seconds is common in our CI environment. Please note that usually giving a larger timeout *does not slow down the tests*, as in an `expectMessage` call for example it usually will complete quickly.
-There is a number of ways timeouts can be defined in Akka tests. The following ways to use timeouts are recommended (in order of preference):
+There is a number of ways timeouts can be defined in Pekko tests. The following ways to use timeouts are recommended (in order of preference):
* `remaining` is first choice (requires `within` block)
* `remainingOrDefault` is second choice
@@ -278,16 +273,16 @@ There is a number of ways timeouts can be defined in Akka tests. The following w
Special care should be given `expectNoMessage` calls, which indeed will wait the entire timeout before continuing, therefore a shorter timeout should be used in those, for example `200` or `300.millis`.
-You can read up on remaining and friends in [TestKit.scala](https://github.com/akka/akka/blob/master/akka-testkit/src/main/scala/akka/testkit/TestKit.scala)
+You can read up on remaining and friends in [TestKit.scala](https://github.com/apache/incubator-pekko/blob/main/akka-testkit/src/main/scala/org/apache/pekko/testkit/TestKit.scala)
# Supporting infrastructure
## Continuous Integration
-akka-grpc currently uses Github Actions for Continuous Integration. See the `Checks` tab in a PR for details about the current run.
+pekko-grpc currently uses Github Actions for Continuous Integration. See the `Checks` tab in a PR for details about the current run.
## Related links
-* [Lightbend Contributor License Agreement](https://www.lightbend.com/contribute/cla)
-* [Akka gRPC Issue Tracker](https://github.com/akka/akka-grpc/issues)
+* [Apache Contributor License Agreement](https://www.apache.org/licenses/contributor-agreements.html)
+* [Pekko gRPC Issue Tracker](https://github.com/apache/incubator-pekko-grpc/issues)
* [Scalariform](https://github.com/daniel-trinh/scalariform)
diff --git a/README.md b/README.md
index 5a8f69e2..9bec6105 100644
--- a/README.md
+++ b/README.md
@@ -1,9 +1,9 @@
-# akka-grpc
+# Apache Pekko gRPC
Support for building streaming gRPC servers and clients on top
-of Akka Streams.
+of Pekko Streams.
-This library is meant to be used as a building block in projects using the Akka
+This library is meant to be used as a building block in projects using the Pekko
toolkit.
## Documentation
@@ -14,7 +14,7 @@ toolkit.
This library is ready to be used in production, but API's and build system plugins are still expected to be improved and [may change](https://doc.akka.io/docs/akka/current/common/may-change.html).
-The API on both sides (Client and Server) is a simple Akka Streams-based one.
+The API on both sides (Client and Server) is a simple Pekko Streams-based one.
The client side is
currently implemented on top of [io.grpc:grpc-netty-shaded](https://mvnrepository.com/artifact/io.grpc/grpc-netty-shaded),
@@ -30,11 +30,11 @@ gRPC is a schema-first RPC framework, where your protocol is declared in a
protobuf definition, and requests and responses will be streamed over an HTTP/2
connection.
-Based on a protobuf service definition, akka-grpc can generate:
+Based on a protobuf service definition, pekko-grpc can generate:
* Model classes (using plain protoc for Java or scalapb for Scala)
-* The API (as an interface for Java or a trait for Scala), expressed in Akka Streams `Source`s
-* On the server side, code to create an Akka HTTP route based on your implementation of the API
+* The API (as an interface for Java or a trait for Scala), expressed in Pekko Streams `Source`s
+* On the server side, code to create an Pekko HTTP route based on your implementation of the API
* On the client side, a client for the API.
## Project structure
@@ -54,8 +54,6 @@ project in Java and Scala respectively, with both sbt and Gradle configurations.
If used with JDK 8 prior to version 1.8.0_251 you must add an [ALPN agent](https://doc.akka.io/docs/akka-http/10.1/server-side/http2.html#application-layer-protocol-negotiation-alpn-).
-Support for Akka gRPC is available via the [Lightbend Subscription](https://lightbend.com/lightbend-subscription)
-
## License
-Akka gRPC is Open Source and available under the Apache 2 License.
+Pekko gRPC is Open Source and available under the Apache 2 License.
diff --git a/benchmark-java/project/build.properties b/benchmark-java/project/build.properties
index 10fd9eee..46e43a97 100644
--- a/benchmark-java/project/build.properties
+++ b/benchmark-java/project/build.properties
@@ -1 +1 @@
-sbt.version=1.5.5
+sbt.version=1.8.2
diff --git a/build.sbt b/build.sbt
index 7de02d7a..218b10d3 100644
--- a/build.sbt
+++ b/build.sbt
@@ -238,7 +238,7 @@ lazy val pluginTesterJava = Project(id = "akka-grpc-plugin-tester-java", base =
.settings(MetaInfLicenseNoticeCopy.settings)
.pluginTestingSettings
-lazy val root = Project(id = "akka-grpc", base = file("."))
+lazy val root = Project(id = "pekko-grpc", base = file("."))
.enablePlugins(ScalaUnidocPlugin)
.disablePlugins(SitePlugin, MimaPlugin)
.aggregate(
diff --git a/project/Common.scala b/project/Common.scala
index cc8b6925..e5cc381f 100644
--- a/project/Common.scala
+++ b/project/Common.scala
@@ -20,22 +20,23 @@ object Common extends AutoPlugin {
override def globalSettings =
Seq(
organization := "com.lightbend.akka.grpc",
- organizationName := "Lightbend Inc.",
- organizationHomepage := Some(url("https://www.lightbend.com/")),
- resolvers += Resolver.sonatypeRepo("staging"),
- homepage := Some(url("https://akka.io/")),
- scmInfo := Some(ScmInfo(url("https://github.com/akka/akka-grpc"), "git@github.com:akka/akka-grpc")),
+ organizationName := "Apache Pekko",
+ organizationHomepage := Some(url("https://www.apache.org/")),
+ resolvers ++= Resolver.sonatypeOssRepos("staging"),
+ homepage := Some(url("https://pekko.apache.org//")),
+ scmInfo := Some(ScmInfo(url("https://github.com/apache/incubator-pekko-grpc"),
+ "git@github.com:apache/incubator-pekko-grpc")),
developers += Developer(
"contributors",
"Contributors",
- "https://gitter.im/akka/dev",
- url("https://github.com/akka/akka-grpc/graphs/contributors")),
+ "dev@pekko.apache.org",
+ url("https://github.com/apache/incubator-pekko-grpc/graphs/contributors")),
licenses := Seq("Apache-2.0" -> url("https://www.apache.org/licenses/LICENSE-2.0")),
- description := "Akka gRPC - Support for building streaming gRPC servers and clients on top of Akka Streams.")
+ description := "Apache Pekko gRPC - Support for building streaming gRPC servers and clients on top of Pekko Streams.")
override lazy val projectSettings = Seq(
projectInfoVersion := (if (isSnapshot.value) "snapshot" else version.value),
- sonatypeProfileName := "com.lightbend",
+ sonatypeProfileName := "org.apache.pekko",
scalacOptions ++= List(
"-unchecked",
"-deprecation",
@@ -56,7 +57,7 @@ object Common extends AutoPlugin {
javacOptions ++= List("-Xlint:unchecked", "-Xlint:deprecation"),
Compile / doc / scalacOptions := scalacOptions.value ++ Seq(
"-doc-title",
- "Akka gRPC",
+ "Apache Pekko gRPC",
"-doc-version",
version.value,
"-sourcepath",
@@ -66,7 +67,7 @@ object Common extends AutoPlugin {
"templates",
"-doc-source-url", {
val branch = if (isSnapshot.value) "main" else s"v${version.value}"
- s"https://github.com/akka/akka-grpc/tree/${branch}€{FILE_PATH_EXT}#L€{FILE_LINE}"
+ s"https://github.com/apache/incubator-pekko-grpc/tree/${branch}€{FILE_PATH_EXT}#L€{FILE_LINE}"
},
"-doc-canonical-base-url",
"https://doc.akka.io/api/akka-grpc/current/"),
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pekko.apache.org
For additional commands, e-mail: commits-help@pekko.apache.org