Skip to content
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

Merged

Conversation

mdedetrich
Copy link
Contributor

@mdedetrich mdedetrich commented Nov 20, 2022

This PR changes the akka package name to org.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 to org.apache.pekko, this also includes any changes that are also effected from the package name, i.e.

  • Documentation (scaladoc/javadoc/paradoc) that used to refer to the akka package name)
    • The paradox config (i.e. project/Paradox.scala) has been updated so that the akka prefix has been updated to pekko. The setting has also been updated so that it correctly points to the org.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 update scaladoc.pekko.base_url/javadoc.pekko.base_url and other related settings once we push our documentation to the website.
  • Any comments that used to refer to the akka package name
  • Generated code from protobuf. From my surface level understanding of protobuf this should not break the wire protocol because the package name/fieldDescriptor for protobuf is only used when generating the package in the source files, specific fields haven't been changed (can someone with more protobuf experience confirm this?)
  • References to akka package in comments

What HASN'T been changed

  • HOCON/akka config
  • Any class names that happen to contain Akka

Other notable changes

  • So far I have only discovered one part of the Akka codebase which computes a HOCON configuration from the package of a FQCN. This is located in the private def createServiceDiscovery(method: String): ServiceDiscovery function inside of org.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).
  • In the PR for Scala sources I have opted to create a top level import org.apache.pekko import and then further imports are done with the pekko 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 are
    • The diff would be much larger, even if we only consider the top level file imports. The current structure minimize's the diff.
    • The org.apache.pekko is a huge amount of noise. From doing this PR I actually share some sentiment with people that were complaining that the org.apache prefix for the root level package would create a lot of machinery. While its already been decided that we are going ahead with org.apache.pekko, referring to top level imports with the pekko root seems like a nice compromise
      • Further more onto this topic, akka also has a lot of inline (i.e. not top of file imports such as import 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.
      • After going though the entire Akka sources multiple times I noticed that in general the imports need to be cleaned up, i.e. in some spaces the imports are randomly split up, java imports are at top versus on the bottom etc etc (in summary they are all over the places). I want to explore using scalafix to automatically clean up imports which means the codebase will be consistent regardless of what peoples editors (Intellij/VScode) does when you add an import to the top of the file. If we want to re-evaluate how the imports look like, I think it makes sense to do it at this point in time.
      • The only exception to this are imports which are within # code blocks, code in such # code blocks are exported in docs as paradox snippets so in such places you may find multiple import 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.

@mdedetrich mdedetrich marked this pull request as draft November 20, 2022 16:24
@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch 4 times, most recently from 055a3cc to ce9c9e8 Compare November 20, 2022 18:20
.scalafix.conf Outdated Show resolved Hide resolved
import akka.annotation.InternalApi
import akka.util.OptionVal
import org.apache.pekko
import pekko.annotation.InternalApi
Copy link
Contributor

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.

Copy link
Contributor Author

@mdedetrich mdedetrich Nov 20, 2022

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
image

I was actually going to provide the reasoning when the PR is done, its still ongoing.

Copy link
Member

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.

Copy link
Contributor Author

@mdedetrich mdedetrich Nov 21, 2022

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)

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch 3 times, most recently from b077acc to 7ac4f6e Compare November 20, 2022 22:50
new TestInboxImpl((address / name).withUid(uid))
}

private[pekko] val address = RootActorPath(Address("akka.actor.typed.inbox", "anonymous"))
Copy link
Member

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?

Copy link
Contributor Author

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").
Copy link
Member

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?

Copy link
Contributor Author

@mdedetrich mdedetrich Nov 21, 2022

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).

Copy link
Member

@jxnu-liguobin jxnu-liguobin Nov 21, 2022

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. 🥲

Copy link
Contributor Author

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).

@He-Pin
Copy link
Member

He-Pin commented Nov 21, 2022

What about akka remote wire protocol and akka persistent?I think there is no way to do rolling migrating from akka cluster right?

@mdedetrich
Copy link
Contributor Author

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.

@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch from 7ac4f6e to b33c98c Compare November 21, 2022 09:37
@jlprat
Copy link
Contributor

jlprat commented Nov 21, 2022

@mdedetrich Do you want to change Scaladoc Javadoc fully qualified references in this PR?
There are 18 occurrences. For example: https://github.com/mdedetrich/incubator-pekko/blob/rename-akka-package-to-org-apache-pekko/akka-actor/src/main/java/org/apache/pekko/japi/pf/DeciderBuilder.java#L10

@mdedetrich
Copy link
Contributor Author

@jlprat

There are 18 occurrences. For example: https://github.com/mdedetrich/incubator-pekko/blob/rename-akka-package-to-org-apache-pekko/akka-actor/src/main/java/org/apache/pekko/japi/pf/DeciderBuilder.java#L10

Thanks, will look at it!

@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch from b33c98c to 45eabb3 Compare November 21, 2022 10:16
@mdedetrich
Copy link
Contributor Author

mdedetrich commented Nov 21, 2022

@jlprat I fixed the fully qualified references in Javadoc

@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch 9 times, most recently from 43a1da6 to 88eb4b1 Compare November 22, 2022 08:12
@mdedetrich
Copy link
Contributor Author

Wahoo, so I have finally managed to get the CI to build however there are still some final steps left over

  1. Need to update all documentation/comment references to old akka.*SomeClass to org.apache.pekko.*SomeClass
  2. Paradox needs to be fixed, although it does statically check hard links to classes a LOT of the paradox documentation uses manual anchor/hyperlink references which are not statically checked, these need to be updated (and I also need to check the generated documentation doesn't have broken links).

@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch 4 times, most recently from bc3df49 to 74f805d Compare November 23, 2022 19:59
@mdedetrich mdedetrich marked this pull request as ready for review November 23, 2022 21:35
@mdedetrich
Copy link
Contributor Author

mdedetrich commented Nov 23, 2022

PR is now ready to review, original post updated

@He-Pin
Copy link
Member

He-Pin commented Nov 24, 2022

I will check this on this weekend, great work.

Copy link
Contributor

@pjfanning pjfanning left a 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.

Copy link
Member

@He-Pin He-Pin left a 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

@mdedetrich
Copy link
Contributor Author

Thanks for the reviews, I will do one last sanity check before merging it into main.

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

Yes this is correct, we will do it in future PR's.

Copy link
Member

@gmethvin gmethvin left a 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.

@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch 2 times, most recently from dd0d80b to fd47724 Compare November 29, 2022 18:19
@mdedetrich mdedetrich force-pushed the rename-akka-package-to-org-apache-pekko branch from fd47724 to e25477d Compare November 30, 2022 10:32
@mdedetrich
Copy link
Contributor Author

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 mdedetrich merged commit f84e8db into apache:main Nov 30, 2022
@mdedetrich mdedetrich deleted the rename-akka-package-to-org-apache-pekko branch November 30, 2022 15:45
@kw217
Copy link
Contributor

kw217 commented Jan 10, 2023

@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., {akka => org.apache.pekko} more cleanly?

@pjfanning
Copy link
Contributor

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.

@mdedetrich
Copy link
Contributor Author

mdedetrich commented Jan 10, 2023

@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 private[akka] OptionVal inside of pekko core (this repo) which is used in pekko-http however due to having to rename the akka package in pekko-http you can no longer access the private[akka] OptionVal since pekko-core hasn't been published yet.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants