recover sanity and finally remove osgi

[jrudolph]

Fixes #685

[pjfanning]

lgtm - seems ok to remove in 1.1.0

We may have to consider our options if this #685 starts happening in the 1.0.x branch.

[pjfanning]

something went wrong in the CI build (validatePullRequest task) - specifically the paradoxMarkdownToHtml part - I've restarted that bit just in case

[10-11 15:40:30.340] [error] (docs / Compile / paradoxMarkdownToHtml) com.lightbend.paradox.sbt.ParadoxPlugin$ParadoxException

[jrudolph]

There are still some osgi docs left: https://github.com/apache/incubator-pekko/actions/runs/6484047238/job/17606979496?pr=705#step:7:28177

[mdedetrich]

I am going to tentatively approve this however at the risk of being "that guy" shouldn't we confirm on the mailing list + other channels that no one is using OSGI before dropping it like this? Last time we tried to suggest to drop something major (i.e. JDK 8) we immediately got pushback because people are still using it. Ontop of this its technically a breaking change (we are using semver).

Note that doesn't mean that we shouldn't also be clear in our messaging that the reason for dropping OSGI is that its currently breaking protobuf jar and so hence we might have to drop OSGI regardless if no one can find a reason why its corrupting our zips (i.e. this is a case of if you really need and use OSGI, then contribute the fix yourself)

[pjfanning]

We can merge this when it is ready and also start a discussion on the mailing list for undoing it. I'm a big fan of the concept that if people want OSGI support that they should contribute positively to maintaining it. Right now, fixing OSGI is non-trivial.

In short term, merging this gets us back to having working builds. In long term, we can expend effort adding back OSGI support but only if there is enough demand and community support.

Akka have removed OSGI support. And it seems that some people were a tad unhappy - not necessarily going to mean we will see complaints. akka/akka#28304

[mdedetrich]

Akka have removed OSGI support. And it seems that some people were a tad unhappy - not necessarily going to mean we will see complaints. akka/akka#28304

Yeah this is exactly what I am talking about. If its okay with everyone I might take a stab at trying to fix the core issue and if it takes too long (i.e. I give up) then we can merge it?

[mdedetrich]

So there is actually a fix for this in sbt-osgi, it just hasn't been released (see sbt/sbt-osgi#81). I will see if we can get this merged and released in a reasonable amount of time, if that doesn't happen then I am fine in merging this PR for 1.1.0

[pjfanning]

Akka have removed OSGI support. And it seems that some people were a tad unhappy - not necessarily going to mean we will see complaints. akka/akka#28304

Yeah this is exactly what I am talking about. If its okay with everyone I might take a stab at trying to fix the core issue and if it takes too long (i.e. I give up) then we can merge it?

My reading of akka/akka#28304 is that the existing OSGI support is not what OSGI users want but that none of them are willing to help to improve it.

My vote is to remove OSGI support now to get our builds working and to consider adding it back later.

[mdedetrich]

My reading of akka/akka#28304 is that the existing OSGI support is not what OSGI users want but that none of them are willing to help to improve it.

I have a different takeway which is that almost all of the discussion is regarding moving akka-osgi outside of the Akka org. Afaics the current osgi is working as intended.

My vote is to remove OSGI support now to get our builds working and to consider adding it back later.

I just got added as a maintainer to sbt-osgi (see sbt/sbt-osgi#82) so we are going to spend the next few days updating the org/making a release with the previously mentioned fix.

Given this it doesn't make sense to merge this now especially considering that this is a breaking change to users whether we like it or not. I really do not like giving out the impression that we just break users without proper consideration.

Since the effort in fixing this is largely trivial I would strongly recommend seeing if a new sbt-osgi release fixes our issue and if it doesn't then we can consider dropping osgi entirely because at least we have a strong justification to do so rather than just jumping the gun.

build is working again

Fixed with #752

[mdedetrich]

Im going to add the 2.0.x milestone to this since if there is community consensus on dropping sbt-osgi its only possible to do it then.

Note that given that fixes for this underlying problem already existed and various people commenting on sbt-osgi (i.e. see sbt/sbt-osgi#93) we are probably under-estimating sbt-osgi's.

Given this I would advocate that we use a community consensus with a formal vote in order to determine if we should drop osgi, especially given that the community has actually solved the underlying bugs (its just that no one on lightbends end was merging and releasing osgi, this is now been resolved since I am a maintainer of sbt-osgi).

[rovarga]

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. 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 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. Fix pekkoImport() range #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.

2. Fix pekkoImport() range #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. 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, the solution being a Gradle plugin which relies on --patch-module, of which JEP 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, 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 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.

[rovarga]

I would also like to point out that this PR's headline could use better wording before it gets merged ;-)

[He-Pin]

@rovarga there will be backport to 1.2.x and 1.1.x，so thanks and it would be nice that all osgi adjustment done at a whole pr.

That's will make backport and write release note easier. Completed forgot how to use osgi since it's ten years ago from my last time using it, so I have to trust you here).

So the best thing is we split the fixes into two pr, one that should be backported and one only for the 2.0.0 branch.

[He-Pin]

And BTW, netty is just recently fixing osgi related things too, pekko is a community driven project, so we need every pr have a detailed description about motivation, modification and result, that will help everyone, but yes, I'm not done that very well too.