While the timing of this can be considered ill-advised considering we have a release candidate down the line, this is something that I have only somewhat recently discovered as I have been working on getting other Pekko modules ready for releases.
What I have noticed is that various Pekko modules (thankfully excluding Pekko core) happen to have dependencies on other projects which in turn also happen to depend on Pekko. This basically creates a transitive circular dependency, i.e. Pekko Http has a dependency on project X and project X has a dependency on Pekko core. In my view this situation isn't really ideal because it opens us to risk of being blocked when having to do some changes and this is what we have actually experienced when working on getting Pekko modules ready for release candidates (https://github.com/lomigmegard/pekko-http-cors/pull/19, https://github.com/pjfanning/aws-spi-pekko-http/pull/6, https://github.com/pjfanning/aws-spi-pekko-http/pull/5 and https://github.com/pjfanning/aws-spi-pekko-http/pull/1) are examples of this. The problematic dependencies are listed below but in a lot of cases PJ Fanning has had to fork the project's and it's at this point that I am raising whether it makes more sense to just put the dependencies directly inside the appropriate Pekko module. Note that the list below is sorted in criticality (i.e. modules closer to Pekko core are placed earlier since they will be released earlier). * https://github.com/lomigmegard/pekko-http-cors: This is not forked by PJ Fanning because thankfully the maintainer has been constructive/responsive in adapting the project for Pekko and merging necessary changes. The project is used by pekko-grpc but it depends on pekko-http since its adding cors (see https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). The natural place for this project would be to sit inside of pekko-http, in fact I am quite surprised that this is in a separate project since this is a W3C http standard. Adding this as a separate artifact inside of pekko-http would technically be quite trivial. * https://github.com/pjfanning/aws-spi-pekko-http is an SPI (Service Provider Interface) to AWS's async API for their services which is a fork of https://github.com/matsluni/aws-spi-akka-http which is currently forked by PJ Fanning. The project depends on pekko-http and is a dependency of various pekko-connecter AWS integrations (i.e. event bridge, kinesis etc etc). It can be its own artifact within pekko-connectors since its transitive dependencies (i.e. aws sdk) are quite stable and don't break that often. * https://github.com/hseeberger/akka-http-json: An integration between Akka Streams and Circe. The project depends on akka-http and is being used by the IronMQ integration in Pekko connectors, currently the project is forked by PJ Fanning. I wouldn't recommend merging this project into pekko-connectors because historically Circe's interface hasn't been that stable (more specifically Circe is still on 0.x on early-semver which means any increase in minor breaks binary compatibility and hence we would be forced to release pekko-connectors very frequently). If the author considers forking this for Pekko than this is acceptable however there are alternatives, i.e. I maintain https://github.com/mdedetrich/akka-streams-json which will be forked in a new repo for Pekko once a change in typelevel's jawn is released (and as a bonus akka-streams-json which will be pekko-streams-circe as an actual streaming JSON implementation, unlike akka-http-json) Including the source of these plugins directly into Pekko raises a lot of concerns. The most obvious ones are legal/license, on the licensing front we are lucky since all of the code in question is Apache 2 however there can be other legal concerns that always arise in these cases. Thankfully we are a bit lucky here in that the author of the most critical module dependency timewise pekko-http-cors has been very open in working with us, so it may not even be a stretch in proactively and honestly asking him whether he would be willing to donate the code (even with a code grant) to us which I would presume would solve most legal issues. The other dependency which is aws-spi-pekko-http might be a bit more problematic but its also part of pekko-connectors which will take some time before we get to a release and by that time pekko core would already have its 1.0.x release which hopefully increase chances of the author being more responsive to us. As mentioned before akka-http-json doesn't make sense because of technical reasons but we should look into approaching the author at some point in making it support pekko irregardless of what we decide on this topic. Also finally regarding the effort both in including the code and in maintaining it, with the former we would just place code in an existing repository. Even for purely technical reasons it doesn't make sense to make the projects their own repo and in regards to maintenance burden a lot of this code is basically unchanged for years so we should be good here. What is everyones thoughts on this? -- 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:* matthew.dedetr...@aiven.io
