My preference is to update all 'akka' anything in Pekko code to 'pekko'. This breaks compatibility but is cleaner (IMHO).
Documenting and ideally, automating migrations from Akka to Pekko is the way forward. Having Pekko code log warnings if it detects Akka on the classpath - this is probably prudent. If we get news from users, that having both libs on the classpath is not working, we may need to consider making Pekko refuse to start. I do see a use case where someone wants to read a message from an Akka actor instance and then forward it to a Pekko actor instance. Supporting users who want to have mixed Akka and Pekko clusters - testing that will be hard. If anyone truly needs that then I think we will need dedicated extra resources for this work. With the current community size, it is hard to see us spending a lot of effort on this - or we will seriously delay a v1.0.0 release. On Wed, 15 Feb 2023 at 16:30, Matthew Benedict de Detrich <[email protected]> wrote: > > Regarding making Pekko automatically handle Akka configuration, I have > doubts as to whether this feature provides as much benefit as is implied. > Configuration tends to be static and I have the impression that a far nicer > solution to the problem would be to write a script that generates any > existing akka config to pekko config rather than making pekko handle akka > config > > On Wed, Feb 15, 2023 at 4:27 PM Jean-Luc Deprez <[email protected]> > wrote: > > > The moment that the "can also parse akka HOCON prefix compat"-feature gets > > introduced things can turn rapidly sour though. > > > > Having both in a single JVM/Classloader tree structure is doubtedly part of > > any future ideal, but I a straight line towards that ideal could be wishful > > thinking. > > Yet, I have sort of set my mind to doing exactly that 🤭 (so avoiding the > > duo) > > > > On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich > > <[email protected]> wrote: > > > > > Akka already has checks to make sure users don't mix and match > > > different artifacts on the class path. There is undergoing work in Pekko > > to > > > remove/fix these checks (i.e. see > > > https://github.com/apache/incubator-pekko/pull/189) however it does > > bring > > > a > > > general point about whether we should check if there are any Akka > > artifacts > > > on the classpath for users running Pekko and produce warnings in such a > > > case. > > > > > > I would predict that generally speaking if you are mixing Pekko and Akka > > > artifacts then this is likely a mistake and you are doing something wrong > > > even though technically speaking with all of the class/package/conf > > changes > > > there shouldn't be any conflicts (basically both ecosystems would sit in > > > their own silos). > > > > > > Thoughts? > > > -- > > > > > > Matthew de Detrich > > > > > > *Aiven Deutschland GmbH* > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > *m:* +491603708037 > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
