On 04/11/2020 20:29, Steinar Bang wrote: >>>>>> Jean-Baptiste Onofre <j...@nanthrax.net>: >> My thinking now is more to still use OSGi internally (and let people >> do OSGi on Karaf if they want) but open the scope to other >> framework/approach (spring boot, micro profile, etc). We would embrace >> a wider community and expend our use cases. > FWIW what drew me to karaf was to finally see OSGi deliver on its > promise. > > OSGi that actually worked like people said it was *supposed* to work, > back in the mid-late 00s... > > I would hate to see that go. > > (Spring boot is not a priority for me. I try to run quickly the other > way when someone mentions Spring or Spring boot...:-) )
Same sentiment here in general, but with a very libertarian twist :) With my various OpenDaylight hats on, let me summarize our project-wide view, with history going back to the project was officially announced (early 2013). From the get go, our *architectural* requirement was OSGi compatibility, i.e. every single production (not maven-plugin obviously) artifact has to be a proper bundle. This, highly technical and implementation-specific, requirement was set down because of two things: 1) what OSGi brings to MANIFEST.MF in terms of headers and intended wiring, incl. Private-Package 2) typical OSGi implementation (we inherited Equinox and are still using it) uses multiple class loaders and utterly breaks on split packages This serves as an architectural requirement that translates to an unbreakable design requirement how the code must be structured. We started up with home-brew OSGi container, which we quickly replaced for karaf-3.0.x (6?), massively enjoying it being properly integrated, with shell, management and all that. Also feature:install. At the end of day, though, OpenDaylight is a toolkit of a bunch of components which you throw together and they work. Our initial thinking was far removed from the current world of containers when operations goes. The deployment was envisioned more like an NMS with a dedicated admin team (to paint a picture), providing a flexible platform. The world has changed a lot, and the focus nowadays is containers providing a single, hard-wired use-case. We now provide out-of-the-box use-case wiring using both dynamic Karaf and Guice (at least for one use case). We have an external project which shows the same can be done with pure Java, Spring Boot and Quarkus. We now also require Java 11, hence we have JPMS -- and it can fulfill our architectural requirement just as well as OSGi and, thanks to OSGi, we have zero split packages :) We do not expect to ditch Karaf anytime soon, but rather leverage static-framework for a light-weight OSGi environment, as that is clearly the best option for us short-to-medium term, and definitely something we will continue supporting for the foreseeable future. The shift to nimble single-purpose wirings is not going away and hence we will be expanding there anyway. To achieve that, we will not be looking for a framework-of-frameworks, we will do that through native integration ourselves. If Karaf can do the same, i.e. have its general-purpose pieces available as components, easily thrown together with @Singletons or @Components, with multiple frameworks, and nicely jlinkable, I grinning silly :) Regards, Robert
OpenPGP_0x537D744B0A1E3F45.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
