Thanks Robert, I get your point and it makes sense. I also think that static distribution is interesting (we need some polishing/small fixes but it works almost fine).
Let’s move forward around that. Regards JB > Le 4 nov. 2020 à 22:05, Robert Varga <n...@hq.sk> a écrit : > > 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>
