Just to make clear to everyone - this does not affect the core Pekko modules and the proposal to press on with getting a RC ready.
I agree that we should not consider taking anything into Pekko that we don't use inside our own modules - that is, only ones that Matthew mentioned are under discussion. At a high level, I'm not against taking in the listed modules but it is a lot of work. * we would need to persuade the original contributors to grant the code to ASF and get it voted on (Pekko community and Incubator PMC) * we have all the work to change the package names and configs * new documentation * new CI builds * a lot more votes on releases We should really consider alternatives on a cases by case basis. * one example is pekko-http-circe - Matthew has highlighted a JAWN based lib that might be a good alternative * aws-spi-pekko-http - an alternative is to use the Java APIs in the AWS v2 libs (which have good async support) All in all, I wouldn't regard taking any of these jars into the Pekko community as something that would block releases. For me, they might be nice to have been the time expenditure on making the changes makes we wary. On 2023/05/30 09:50:34 Matthew Benedict de Detrich wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
