Hi Serge, Tooling and packaging are clearly where we should do better, we know it and we already started improvements around this.
Regarding the "front side", yes, it makes sense. You did it, other Karaf/OSGi users made something similar as well. It could be a Karaf feature obviously. I will write down the points on wiki about this discussion. Thanks guys, that’s great feedback and help to define the roadmap to Karaf 5. Regards JB > Le 4 nov. 2020 à 23:07, Serge Huber <shu...@apache.org> a écrit : > > Interesting discussion going on here. > > Personally from an architectural point of view I really like what OSGi > brings to the table in terms of dev discipline, but its true that when > integrating with libraries that were not designed for OSGi (most of them > were not) it can quickly become problematic. So I'm not sure what could be > done in terms of tooling but at my company we have developed some Maven > plugins that go quite far with dependency calculation and packaging, maybe > something like that could help if we keep the OSGi runtime (which I believe > we should). > > Provisioning also needs improvements, because right now we are looking at > container-packaged Karaf runtimes that need to be properly managed in terms > of upgrading, etc. Having simpler ways (with minimal Maven work) of > packaging Karaf distributions would be really good here. Some work has > already been done here but I think we could probably go further to make it > simpler (looking at Spring Boot or Docker-like syntaxes for example). > > It would also be great to have ready-to-use configurations for build REST > APIs, GraphQL APIs, and possibly even UIs. At my company we've been working > on frameworks to be able to aggregate Javascript components on the server > side that then would be automatically merged on an HTML page. Making it > possible to simply deploy a new bundle with embedded Javascript components > that could extend the UI. Having this as a basic framework would help > building powerful and flexible front-ends in a more guided way, hopefully > improving dev productivity. I'd be more than willing to share my experience > here. > > These are just the first things that come to my mind, I hope they'll help. > > Regards, > Serge... > > On Wed, Nov 4, 2020 at 10:06 PM Robert Varga <n...@hq.sk> wrote: > >> 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 >>
