-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recover sanity and finally remove osgi #705
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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 |
There are still some osgi docs left: https://github.com/apache/incubator-pekko/actions/runs/6484047238/job/17606979496?pr=705#step:7:28177 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
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 |
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? |
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 |
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. |
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.
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. |
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). |
Fixes #685