Open danischroeter opened 1 year ago
I think the first step here is understanding all the things that would need to change in someone's app, so we can develop a strategy for each.
The first obvious step is to change the akka- dependencies to pekko- dependencies, and replace the package name in the codebase. But I'd imagine most production applications running Akka have at least one third-party dependency that's not an official Akka library, so we also need to migrate those to the equivalent compatible version. Maybe the best solution there is to allow the user to provide a mapping of dependencies (groupId, artifactId, version) to their pekko equivalents, and we can provide a suggested mapping for common libraries.
Another tricky thing is how to handle configuration. I think it's too risky to just provide a tool to migrate the configuration file itself, since configuration can come from many different sources in a real production app. We'd probably want a way to tell pekko to look at both pekko and akka prefixes, or a list of arbitrary user-specified config prefixes.
Then there's the question of how to migrate akka remote/artery applications away from akka://
. This is another situation where we probably want to make it configurable in Pekko, so the user initially wouldn't have to do anything.
Ultimately I imagine what we'd want to have is a migration guide, with some automated tools to handle parts of the migration.
Another tricky area will be migration of akka persistence. Especially around the serializers as they might leak some akka references too.
I guess, documenting trial and error hand conversions with 'early builds' would be meaningful input?
I'm setting up a simple scalafix rule to at least take care of the imports in Scala files (though that's also easy to change using search/replace).
Does this need to go into Pekko 1.0.0 milestone?
It seems to me that this is a 'would be nice if' item that could go into the pekko 1.1.0 milestone.
I found migration of pekko-samples using the migration guide was quite a lightweight initial solution. In my view, getting a pekko 1.0.0 release out that people can work with sooner is probably more beneficial than having a neat set of migration tools to accompany.
This is not a release blocker. We can live without it but can we leave it open in case someone wants to try to do something with it?
Ok I think that sounds fine. Could we label as 'nice to have (low prio)' so that people can see that?
Useful but not going to be a blocker for '1.0.0' release
Hi! I wrote an scalafix migration rule in https://github.com/jtjeferreira/pekko-scalafix which I unit tested in a small sample, but also which I tested locally against an akka-sample project
Would you accept a PR of this code? Or should I publish it myself?
Thanks @jtjeferreira
We're running into real issues with getting a release done. A lot of them are arguments about process and others are about copyrights and stuff like that.
For me, it's better if people release their own code. As soon as we take it on, we have to jump through loads of non-code hoops.
I had a quick look at the code you have. I'm not a Scalafix expert but I'm not sure if your changes cover some pretty common renaming issues. You cover the package name fixing but there are class names with Akka in them and we replace those with Pekko.
https://pekko.apache.org/docs/pekko/current//project/migration-guides.html covers Pekko core. @jtjeferreira Your changes look a useful tool - and it's good that you've also supported Alpakka migration.
Is there anything that can be done to migrate configs?
You cover the package name fixing but there are class names with Akka in them and we replace those with Pekko.
Thanks, I fixed those
Is there anything that can be done to migrate configs?
I am not s scalafix expert either, but I don't think so...
scala-steward can also run scalafix migration rules (https://github.com/scala-steward-org/scala-steward/blob/main/docs/scalafix-migrations.md) when opening pull requests.
We should provide some automated migration that users of akka can use that adapts their codebase to use pekko.
This migration should automatically