Remove OSGi support #28304
Comments
raboof
added
help wanted
|
Well, that is quite a hit to our project. Not having the metadata in the artifacts anymore pretty much means we would have to repackage the libraries in one form or another. I guess, from our perspective we would end up with one or more 3rd party modules in https://github.com/woq-blended/blended. In terms of effort it is hard to judge at the moment. Not sure if it would make sense to spin off something like an Akka-Osgi project for the packaging and then reuse the artifacts from there. As we are a very small team we would probably keep it in the main project for starters. |
Yes, we understand - that's why we reached out to discuss if we can find a way to approach this so that it doesn't break your niche-but-interesting use case entirely, but also removes the complexity/risk from our build. As said none of us are particularly up-to-date on OSGi, so it's not clear what is possible... |
|
I see your point and I am grateful you have given us a heads up. As for know we are on 2.5.x with our project. I guess I will discuss with @lefou how to move forward. For us, it is essential to have Akka support in OSGi, so I guess we will put it on our agenda. |
|
I personally moved to container orchestration for modularity and |
|
I don't think, we are the only users though. E.g last week a video was published from EclipseCon Europe 2019 demoing Akka in OSGi (https://www.youtube.com/watch?v=6I1fe5L_btA). @raboof Have you any pointers to get an idea what kind of issues you had in the past with the OSGi support? Technically speaking, building OSGi bundles is just a post-processing (with bnd) of the class files, at least for all the main akka packages, and sbt-osgi encapsulates this quite well. It's probably easier for (one of) us to help out with that, than bootrapping a new OSGi wrapper project. |
|
I started handling the BND post process as a custom SBT plugin in my old builds. |
|
Hi again, in case you really drop the OSGi support, after an initial discussion we tend to maintain the OSGi support in a separate project with a reference to the underlying released akka version. At the moment we cannot judge what effort that will cause and would maintain the project on an as needed basis. In other words, not every Akka release might end up with proper OSGi support. In all, we could use parts of our established OSGi build and test process and use a tool chain that we understand. |
That sounds great! Is there anything we can do on the Akka side to facilitate?
Yes, that makes total sense. |
|
Hm. At the moment we are busy to implement ansible support for setting up our containers. I think, after that we would start looking into continued akka support as we wanted to upgrade our akka stack anyway. Timewise I think, mid - end of January we would start looking into the task and start with Akka 2.6.0. If we hit any show stoppers we would open a ticket in the core project and hope someone can help us. From the first thoughts, most likely we might drop akka-osgi as we are not using it and it only has some classpath magic to resolve configuration properly. Initially we would concentrate on having akka bundles with properly exported API's. |
|
Sad to hear no more OSGi support .. I think adding OSGi support externally is a bad idea. |
Hi again, I would be interested to hear what your use cases are for using Akka in OSGi space and more reasoning why you think an external project is bad. From my perspective there are advantages and disadvantages. As we are relying on Akka within a larger, productive OSGi setup for us it is important that we have continued OSGi support in one form or another. So far we are leaning towards an external project, but I guess we could be convinced with other arguments than "it is bad" ;) Best regards |
|
OSGi meta data is inherent to a jar. It is easy and almost fully automated to create. If your experience is different then I wonder how you create your OSGi metadata. Normally you just add the bnd-maven-plugin and do some minimal config. Not sure how this works in gradle but I know there are bnd plugins too. If you add the meta data in a separate project it means that you have different maven coordinates for the same jars that just differ in their Manifest. This confuses people for no good reason. |
|
I think, the ideal case is to maintain OSGi metadata inside this project. No doubt about that, as long as the project team knows what it does or needs to do. Especially the users will profit from an continued in-project support of OSGi, as @cschneider has very well pointed out. But the Akka team made it clear, that they neither use OSGi themselves nor are they familiar with all the small implications OSGi brings with it. So IMHO, what is really needed is a way to effectively support the OSGi metadata/bundles by people which are currently not part of the Akka team. And here we possibly face some different requirements. Just to name one very personal issue: Although I saw, used and contributed to a lot of build tools, including sbt, I find it sometimes hard so setup some otherwise relatively easy things in the Akka build setup. As said before, this is very personal, but if it should be me who is maintaining the OSGi support in the future, the chance to do it in a different setup is no disadvantage. As Akka is a dependency for our OSGi based project https://github.com/woq-blended/blended in which I work together with @atooni, we will work on or contribute to the OSGi support in one way or the other. Please note, that to date we already wrap the Akka Http JARs as these also dropped OSGi support a while ago. Doing all the Akka wrapping in one external project and release new versions when needed feels like the easiest way for us. |
|
I don’t exactly remember the changes I committed at this point, but IIRC they were mostly minor import/exports that BND couldn’t deduce and they would have been difficult to find without exercising the APIs. I wonder if it would be possible to build something into the test libraries such that tests could be exercised with OSGi active. This could give Akka team more direct visibility of failures (or the ability to auto-nag someone who knows OSGi to tweak the BND instructions). Unfortunately, this would make the build more complex instead of less so it might get vetoed. They’d need to be able to release even if there were I corrected OSGi failures and if OSGi was always on the list of known issues, it might get very unpopular for the team. I agree with @cschneider’s points from a user perspective tho. It’s just a difficult situation when a core team doesn’t see a strong value prop for a feature. Developers are also users (of the build), and if the build (as a product) fails to delight, like any product, it’s probably not sustainable. |
|
I do see your points and all of them are very valid. At the end of the day, the question is not whether we know how to add OSGi metadata to a jar. I guess all of the thread participants know pretty well how to do it and have their preferred solution in their own OSGi related projects. The question really is how could we continue OSGi support for Akka, or in other words continue to use Akka within OSGi (which is the essential part at least for @lefou and myself). I do see 3 options:
Personally, for me Option 3 is a nogo. Option 1 would be the preferred option for everyone - except the Akka team unless they have help committed. With option 1 we do have the problem, that the build process for Akka has a slightly different approach for applying plugin configs to modules than we have in our own project. Neither approach is better than the other, it is just different. If we were to support OSGi within Akka itself, we would have to dive into akka´s build setup and at least come to a point where we can run and verify the OSGi related tests in our own build environment. We wouldn´t want to bother the Akka team every time we make a change to come back to us with feedback whether it works or not. With option 2 we would have slightly more flexibility from a developers perspective. I do understand, that from a users perspective it might be a bit more confusing. As @lefou already said, as of today we are already wrapping the akka-http libraries as OSGi support for them was dropped a while ago. When I argue for option 2 my main concern is the time we would have to invest to get it to a supported level and then maintain it in the foreseeable future. Currently, with option 2 we do see that we get more benefit for the same amount of time invested in option 2 than in option 1 as option 1 has many inknowns that we currently cannot judge. |
|
FYI. We started to evaluate having the OSGi bundles from the released Akka version in https://github.com/woq-blended/akka-osgi. For now we are testing with a subset of bundles and will add those that we require for our own project and for the JDK(s) we require. @raboof: For the first couple of bundles we have found some packaging inconsistencies we might want to discuss. Do you have any preference where we would do that ? - I guess, OSGi related tickets will not be at the top of any priority list ... |
|
ccompat should be internal classes so shouldn't be too difficult to move without breaking, I think. Please open an issue/pr in akka-http. |
|
We will work through the bundles we require for our project and capture the packaging issues in issues in our own project linked to issues we create in akka itself. Later on we can have a look at other modules and cross builds. |
|
Hello, in our process to upgrade our project to Scala 2.13 we also would like to proceed to the latest akka version. I have just seen, that i.e. akka-actor still has OSGi headers in akka 2.6.4. Has the plan to remove OSGi support changed ? |
|
It hasn't changed, so we are curious about if your approach can become a recommended replacement. |
|
By request of @atooni a little something about our use case of akka in OSGi. We are running the classic combo of apache camel, activemq and cxf inside karaf for a couple of years now. Some time ago we added akka-actor to the mix inside a single bundle to function as some sort of connection monitor. Recent use cases require us to share (quickly changing) state between bundles and even karaf instances. Since we already have experience running OSGi and have been using quiet a lot of akka modules for other projects, this is our first go-to implementation for an in-memory distributed data store solution. |
|
@barthorre Than you for this - this is exactly how we started a while ago. Meanwhile we have migrated completely from Camel to Akka Streams and have replaced Karaf with our own Scala based framework. The concepts remain :) |
|
FYI: In our technology upgrade we are now addressing OSGi support in an external project: akka-osgi is the project to build OSGi enabled manifests for the existing akka jars. blended is our main project with a large collection of |
Understood, but that essentially means mirroring almost all com.typesafe jars :(
We have an automated test suite which validates things with pax-exam. For that particular patch the result can be seen here: |
Yes, we are aware of that. Thanks for the pointers to your information. I ll try to take some time looking at it the next couple of days. |
|
@mpilquist is running an informal little poll on this subject: https://twitter.com/mpilquist/status/1454177597668175873 we removed OSGi support from some of the Scala modules a while back and haven't had any complaints |
|
We've kept OSGi around until now, but it is currently holding back building Akka with Java 17 (#31437). If someone could help with resolving that issue that would be great ;) |
|
Being an old-skool Java dev, I wonder what the real problem is. Given that maven-centric world has zero problems with OSGi , with two plugins being readily available... this issue feels like it is mostly as tooliing problem. I do not quite grasp why sbt-osgi does not do the equivalant of bnd-maven-plugin, i.e. run bnd.org tools to generate MANIFEST.MF. On Akka side, the requirement boils down to "no split packages". That exact requirement is dictated by JPMS. While I understand binary complatibility issues, at some point Akka will need to clean up its act. The message is:
Ditching OSGi support is shooting the messenger rather than acting of the message. Yes, OSGi can be tricky. at times. No, that is not the case here. We are talking about Import-Package and Export-Package manifest headers. Both of those can be auto-generated. Akka only needs to solve the split package problem. That problem is not OSGi-specific and I can give concrete examples where split packages have broken downstreams just by $TIMEDATE shifting. |
|
@rovarga I’m sorry that your Akka on OSGi experience is not delightful. Open source software always has a 100% money-back guarantee for those who are not satisfied. Seriously, I remember when people would occasionally write word processors with macro assemblers. Processor purists could regale that their word processor did not execute a single unnecessary instruction. But it didn’t matter much because processor purists were rarely poets. Or at least there were not enough of them to support said word processor company with paid purchases. I was once a dedicated contributor to the Akka on OSGi efforts. I once had a similar perspective to yours and remember similar responses as this to my advocacy. I realized OSGi does not inspire passions of folks that would rather dedicate their precious cortex to where the deployment puck is going than where it’s been. In an age of rolling restarts of orchestrated container armies, OSGi is an answer in search of a question. Even if you were to fix Akka on OSGi, it’s still going to add integration constraints on developers. In my experience, they have far more passion for other pursuits. It wasn’t that they pushed against OSGi, they just didn’t understand it, want to use it or be held back by it. I’d suggest what was once suggested to me: “Contributions are welcome”. |
|
@rovarga Just to clarify thinks up. sbt-osgi is using bnd-tools (the same tool used by bnd-maven-plugin) under the hood. Unfortunately, sbt is such a complex beast (from an integrator perspective), that it's hard to get bnd integration right. E.g the latest issue is only a consequence of that fact.
I'd really like to fix it (already started), but have neither the time, nor the skills (sbt) nor the motivation (I currently don't use akka) to do it on my own without additional help. My only motivation left is the fact that I would like to see it fixed and I'm already involved in it. Also, I'd like to see good OSGi tooling in Scala land in general, for those using OSGi. But as there is nobody to engage to my questions in the sbt channels, I doubt, I can't do anything. |
|
Just a little update from me: I no longer have any project that requires Akka in combination with OSGi. So, my motivation to maintain OSGi Metadata for a now commercially licensed project with a way too hard comprehensible build setup is simply not high enough. If anybody want to fix this, e.g. by generating OSGi Metadata in an external project, I suggest to do it with Mill. I myself maintain the mill-osgi plugin which works pretty well. Also, the prototype project we started earlier together with Andreas, https://github.com/woq-blended/akka-osgi, might be a good starting point, including a test setup. |
johanandren
added
3 - in progress
|
Given the lack of interest in OSGi support, and the complexity it adds we have decided to drop support. Users who need OSGi will need to repackage or find some other solution. |
* build: Drop OSGi support #28304 * Cleaner inclusion of JDK9+ classes * migration guide, drop osgi page
Our OSGi support makes the build quite a bit more complex and has caused us problems with releases in the past. While there's a couple of projects known to use OSGi, none of the core team has OSGi experience, so we would like to move it out of the main project for 2.6.2. This would include both the artifact metadata (sbt-osgi bundling) and the akka-osgi subproject.
@lefou @atooni @briantopping @oheger @Falmarri you have all contributed to OSGi support in some form or other in the past, would any of you be interested in exploring how to maintain OSGi support for Akka outside of the main Akka project?
The text was updated successfully, but these errors were encountered: