-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename akka package to org.apache.pekko #58
Rename akka package to org.apache.pekko #58
Conversation
055a3cc
to
ce9c9e8
Compare
import akka.annotation.InternalApi | ||
import akka.util.OptionVal | ||
import org.apache.pekko | ||
import pekko.annotation.InternalApi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to not import org.apache.pekko and to fully qualify the imports like pekko.annotation.InternalApi.
IDEs like IntelliJ issue warnings about pekko.annotation.InternalApi style imports even though they are valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to not import org.apache.pekko and to fully qualify the imports like pekko.annotation.InternalApi.
I did it this way because it significantly reduces the diff and it also improves the quality of the produced documentation. In some places if you use the FQN it creates so much extra boilerplate that it also changes the scalafmt significantly and it also created large amounts of boilerplate in Scaladoc comments.
IDEs like IntelliJ issue warnings about pekko.annotation.InternalApi style imports even though they are valid.
At least on my machine Intellij has never produced such a warning, here is a snippet
I was actually going to provide the reasoning when the PR is done, its still ongoing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we just keep it as FQCN, as spark and flink project is doing the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flink is irrelevant because its largely a fully Java codebase now where you have to use FQCN and Spark doesn't use paradox to generate documentation from existing Scala code. As I said before, the bigger issue is that significant portion of Akka codebase uses the akka.<SOMETHING>
package shorthand in return types (as an example). Changing that to org.apache.pekko.<SOMETHING>
does significantly increase the codesize (in other words its not just imports). It would also make cherry picks from Ligthbends Akka less trivial.
I am not completely against using a FQCN but I would strongly recommend changing it in a future PR, not this one and possibly only for 1.1.x. Changing to use FQCN right now would take a really long amount of time (these changes already took a long time)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say ultimately, we'd want fully-qualified imports because that's what everyone uses and also what IDEs usually create.
Regarding, the usages in code directly, I agree with your approach, it doesn't make sense to use FQCN in that case.
In any case, if you made significant changes and it works like this, cleaning up the imports can be done later, indeed. It will unfortunately lead to lots of conflicts so we should do it rather soon, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is already consensus on this I can have a look at it, but I will do so after everything else is done.
b077acc
to
7ac4f6e
Compare
new TestInboxImpl((address / name).withUid(uid)) | ||
} | ||
|
||
private[pekko] val address = RootActorPath(Address("akka.actor.typed.inbox", "anonymous")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I have seen so far no, there are still some tests that need to be fixed but the actor address doesn't seem to effect anything.
/** | ||
* Obtain time remaining for execution of the innermost enclosing `within` | ||
* block or missing that it returns the properly dilated default for this | ||
* case from settings (key "akka.actor.testkit.typed.single-expect-default"). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Continue to use akka configuration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this will be done in a future PR, this PR is only about package change (and its already big enough).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, opening it on MacBookPro M1 pro will cause Chrome to crash. 🥲
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I was going to say in the PR text (which I will update once PR is done) that forget about viewing it in github UI, you will need to checkout the branch locally and use a good git diff viewer (intellij one works wonders here).
What about akka remote wire protocol and akka persistent?I think there is no way to do rolling migrating from akka cluster right? |
This will also be done in a future PR. This PR is only about changing the package name and any other relevant code changes that are necessary so the build doesn't fail. Also do note that the reason I created the draft PR is so I can run tests against the CI, its not ready and I need to update the original PR once its ready. |
7ac4f6e
to
b33c98c
Compare
@mdedetrich Do you want to change |
Thanks, will look at it! |
b33c98c
to
45eabb3
Compare
@jlprat I fixed the fully qualified references in Javadoc |
43a1da6
to
88eb4b1
Compare
Wahoo, so I have finally managed to get the CI to build however there are still some final steps left over
|
bc3df49
to
74f805d
Compare
PR is now ready to review, original post updated |
I will check this on this weekend, great work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed using Github Desktop tool.
Changes look good - thanks @mdedetrich
With a PR this size, it is impossible to check every line in the diff but I think any issues can be fixed later. Key thing is that the CI still works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked it locally with IDEA, so LGTM.
TODO:
- config reference is till akka need to be updated to pekko.
- project fold is still akka prefixed
I think those two can comes in later PRs
Thanks for the reviews, I will do one last sanity check before merging it into main.
Yes this is correct, we will do it in future PR's. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I checked out locally and looked over most of the changes, which seem correct, and the CI still works so I'm convinced this is probably fine.
dd0d80b
to
fd47724
Compare
fd47724
to
e25477d
Compare
So I am going to merge the PR now, I noticed some more discrepancies in the paradox documentation and after screening it a few times I think I got all of them out. |
@mdedetrich we'll need to do something similar with all the other repos. How did you do this rename - what tool assistance did you use, vs just working through thousands of files manually? Was it just a global search and replace, or is there an IntelliJ or other refactoring that can handle, e.g., |
We won't be doing the package rename in other repos yet. We need to start publishing builds from this repo first. The Akka imports in other repos are a mix of classes from this repo and the downstream repo and it will be easier to change them altogether. |
@kw217 I have actually already started working on this for pekko-http since we already have some major open PRs against it which is causing merge conflicts and I am started hitting problems, i.e. there is a I might figure out some workaround but it would exceptional only for pekko-http (due to the open PR's against it such as Scala 3) but I am with broad agreement @pjfanning, its a bit early and we are likely going to hit similar issues in other repos. |
This PR changes the
akka
package name toorg.apache.pekko
. Right before I start, if you value your sanity and/or time I STRONGLY recommend that rather than viewing this PR in github UI, checkout the branch locally and use a good git diff/log viewer (the Intellij one is very good).The basic premise is to change every package name from
akka
toorg.apache.pekko
, this also includes any changes that are also effected from the package name, i.e.akka
package name)project/Paradox.scala
) has been updated so that theakka
prefix has been updated topekko
. The setting has also been updated so that it correctly points to theorg.apache
root package prefix. This means that while currently the links in paradox aren't valid (since they point to akka.io's scaladoc), one just needs to updatescaladoc.pekko.base_url
/javadoc.pekko.base_url
and other related settings once we push our documentation to the website.akka
package nameakka
package in commentsWhat HASN'T been changed
Other notable changes
private def createServiceDiscovery(method: String): ServiceDiscovery
function inside oforg.apache.pekko.discovery.Discovery
and the details have been annotated with the// TODO: Update the org.apache.pekko to akka workaround when HOCON config gets updated
comment (i.e. when HOCON gets updated to pekko then that function needs to be updated to point to pekko conf).import org.apache.pekko
import and then further imports are done with thepekko
root (i.e.import pekko.actor.ActorRef
). Some people have commented that they prefer to have every import as a FQN import, my counter arguments to this areorg.apache.pekko
is a huge amount of noise. From doing this PR I actually share some sentiment with people that were complaining that theorg.apache
prefix for the root level package would create a lot of machinery. While its already been decided that we are going ahead withorg.apache.pekko
, referring to top level imports with thepekko
root seems like a nice compromiseimport pekko.actor.typed.scaladsl.adapter._
) which if using FQCN take a large amount of horizontal space in an area which most people arguably want to minimize code that takes up large horizontal amount of space.#
code blocks, code in such#
code blocks are exported in docs as paradox snippets so in such places you may find multipleimport org.pekko.apache
(or none at all) depending on the code in question. Also if there is only ever one import in the entire source file then this will be a FQCN import.The PR should now be in enough of an advanced state that it can be reviewed, I will go through it a few more times in the next coming days to see if I have missed anything.