rovarga commented on PR #705: URL: https://github.com/apache/pekko/pull/705#issuecomment-3239414887
I have a project which has been using Akka with OSGi for a long time. The relationship has been contentious, mostly because of sbt-osgi not working (as noted above) and stakeholders being largely Scala/sbt-ignorant (I count myself in that camp). At some point we just gave up and started treating Akka as we would any other broken upstream, by [repackaging it for ourselves](https://github.com/opendaylight/controller/tree/10.0.x/akka). This is a far from optimal, but this particular hammer solves five things in one go: 1. split packages disappear, as everything is now in one jar 2. familiar and known-to-be-good tooling 3. explicit control over which parts of upstream are being handled 4. quick detection of regressions/quick turnaround on fixes 5. no cross-project tension Now we have migrated to Pekko-1.0.x, then to Pekko-1.1.x and have just switched to Scala-3 versions of Pekko-1.1.5, I have conducted an experiment to [undo the repackaging of Pekko](https://git.opendaylight.org/gerrit/c/controller/+/117781) and it is turning out issues in Pekko's OSGi metadata. While I share @mdedetrich's sentiment on the issue, I also have to ackowledge the following facts: 1. #2111 shows a bit of customization, which I do not believe should not be there: Pekko follows SemVer, hence imports should always be `[x.y,x+1)` -- i.e. the default we get from `bnd`. This should be relatively easily fixed, but I honestly could not find a definitive "this is how you do OSGi with SBT" guide -- though it has been requested [a long time ago](https://github.com/sbt/sbt-osgi/issues/56). 2. #2111 also demonstrates that the OSGi metadata is not validated during the build. There are multiple ways this can be achieved in Maven/Gradle and Apache Karaf provides a plugin which drive such validations [quite easily](https://github.com/netty/netty/tree/4.2/testsuite-karaf). I am not sure how to do that with SBT. 3. Scala 3 is actively hostile to both JPMS and OSGi due to `scala3-library_3` containing split packages with `scala-library`. This has been [reported to byte Scala users](https://users.scala-lang.org/t/gradle-7-6-jdk-19-and-scala-3-java-lang-classnotfoundexception-scala-predef-even-though-scala-library-2-13-10-jar-is-in-classpath/8972), the solution being a [Gradle plugin](https://github.com/java9-modularity/gradle-modules-plugin?tab=readme-ov-file#patching-modules-to-prevent-split-packages) which relies on `--patch-module`, of which [JEP 261](https://openjdk.org/jeps/261) says, in bold: `The --patch-module option is intended only for testing and debugging. Its use in production settings is strongly discouraged.`. OSGi has a trivial solution for this, which is for `scala3-library_3` be a Fragment Bundle attaching to `scala-library`. JPMS requires [repackaging the two to get a combined jar](https://github.com/opendaylight/controller/commit/1a0cbc63cb2efb852f4b7633926a88aa6f4c32cd) , as I could not find an equivalent in Maven Central. It is the third point that really hurts: even if we solve 1) and 2), there is no clean way to deliver that with Scala 3. Not without support from the Scala 3 team. They are going to be [moving to Java 17](https://www.scala-lang.org/news/next-scala-lts-jdk.html) soon. I suspect soon after that users will start asking questions about Scala 3 + SBT + `module-info.java` -- at which point Scala will have to figure out its JPMS interop story. Once it does, having reliable OSGi metadata is going to be trivial, as `Import-Package`/`Export-Package` are just `requires`/`exports` or steroids. With all that context, I am fine with Pekko not shipping with OSGi metadata, as maintaining the repackaged jar I already have is easy enough. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
