On Thu, Nov 5, 2020 at 5:50 AM Jean-Baptiste Onofre <j...@nanthrax.net> 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 <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 > >> > >
