When I checked akka-persistence-mongo at the weekend, it has a dependency on reactivemongo-akkastream which has a dependency on reactivemongo (which also has an akka dependency).
This might have changed for the pekko equivalent. Even if it has, I'm still going to argue against Apache Pekko taking on any more code until we get the current code set of Pekko modules released. And that will take months. After that, I would probably start arguing to REDUCE the Apache Pekko code base as opposed to increase it. There are a lot of connectors that have broken tests or tests disabled. It's hard enough to support and test the core Pekko features (like Actors, Clustering, HTTP, etc.), while then also having to maintain all the integrations with a huge variety of 3rd party tools. It's taken us 8 months to release the Pekko core. We simply can't handle the enormous size of the current code base. We need to concentrate on the core tooling. Let the people who need the integrations (connectors and persistence implementations) maintain them. On Mon, 17 Jul 2023 at 18:30, Brendan Doyle <[email protected]> wrote: > > That’s fine I expected that to be the outcome for the reasons you listed, > but wanted to raise the discussion. Though I am curious what you mean by > the lib dependencies that don’t support pekko, which library dependencies > are you referring to within? The maintainers of the akka mongo persistence > library have already successfully ported a pekko repo which I linked , > they’re just working through some artifact publishing issues before a > release happens. > > On Mon, Jul 17, 2023 at 10:03 AM PJ Fanning <[email protected]> wrote: > > > I'd be a strong -1 on this. > > > > Maybe in distant future. > > > > There are too many lib dependencies in that module. None of which support > > Pekko. > > > > Software brought into ASF requires permissions from all the past > > contributors. Pekko itself is an exception because of the Akka license > > change. > > > > ASF requires us to do loads of process work and read every line to check > > its origin in case of licensing issues. Everything required multiple votes. > > > > Why don't you start by talking to the existing lib maintainers about them > > releasing Pekko libs? If that doesn't work out, you could fork them > > yourself. > > > > Pekko team have far too much code and too few active developers to become a > > shelter for all the old Akka libs that no-one wants to maintain. > > > > On Mon 17 Jul 2023, 17:31 Brendan Doyle, <[email protected]> wrote: > > > > > Whoops forgot to include the link to the repo. > > > > > > https://github.com/scullxbones/pekko-persistence-mongo > > > > > > > > > On Mon, Jul 17, 2023 at 9:26 AM Brendan Doyle <[email protected]> > > > wrote: > > > > > > > Hi, > > > > > > > > The skullxbones mongo persistence library was the de facto connector > > for > > > > mongo, never having a dedicated library from Lightbend. The creator > > and a > > > > collaborator have already successfully ported the library to pekko > > 1.0.0 > > > > and are working on getting a release out. The port has dropped support > > > for > > > > reactive mongo and only using the official mongo-scala-driver going > > > > forward. They would like to see the library donated to pekko if the > > > > community / team would be interested. I know there’s a couple official > > > > persistence libraries for widely used db’s like dynamodb, personally > > > though > > > > biased I would argue mongo falls into that category. I’m not sure what > > > the > > > > bar or threshold is to take in another repo or if there’s a long term > > > plan > > > > to combine persistence drivers into a single repo like the way stream > > > > connectors are set up besides kafka. > > > > > > > > Thanks, > > > > Brendan > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
