Yep, first step can be providing some backend api for administration like we already have in Cave.
regards, François [email protected] Le 05/11/2020 à 14:11, Serge Huber a écrit : > On Thu, Nov 5, 2020 at 5:50 AM Jean-Baptiste Onofre <[email protected]> wrote: > >> 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. >> > That is exactly my point: people should not be re-doing stuff over Karaf :) > If they want to do their own that's fine but it would be great to provide > something optional that goes a long way to provide the basic infrastructure > for modern and pluggable UI building. > > cheers, > Serge... > > >> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> On 04/11/2020 20:29, Steinar Bang wrote: >>>>>>>>>> Jean-Baptiste Onofre <[email protected]>: >>>>>> 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 >>>> >>
