You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2020/11/04 04:59:37 UTC
Thinking about Karaf 5 modulith runtime
Hi guys,
François and I started to think about Karaf 5 and give an even modern flavor to Karaf, including potentially lot of refactoring and changes. We think it’s a must have in our patch to the "main modulith runtime".
Before sharing all details (some have been shared during my talk at ApacheCon), we want to move forward on a PoC branch.
However, we would love to have your inputs and thoughts (think wide ;)).
So, please, if you have ideas, comments, criticism ;), send me an email and I will reply and eventually include your points in the PoC.
Thanks !
Regards
JB
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Big +1, and the good point about Romain’s proposal is that we have two different subproject:
- Karaf OSGi runtime where we can focus on the tooling, etc
- Karaf runtime manager where we can focus on runtime, multi runtime tooling, assembly
Regards
JB
> Le 4 nov. 2020 à 10:51, Francois Papon <fr...@openobject.fr> a écrit :
>
> Agree and we have to focus on building the distribution and testing easily.
>
> regards,
>
> François
> fpapon@apache.org
>
> Le 04/11/2020 à 10:21, Jean-Baptiste Onofre a écrit :
>> Changing the "perspective/cursor" with Karaf as "runtime backbone", where OSGi is a kind of runtime, at same level as spring-boot, micro profile, whatever, is actually very interesting.
>>
>> It could gives "perspective" to the project:
>> - Karaf OSGi runtime
>> - Karaf runtime manager
>>
>> I like the idea ;)
>>
>> Regards
>> JB
>>
>>> Le 4 nov. 2020 à 09:39, Romain Manni-Bucau <rm...@gmail.com> a écrit :
>>>
>>> This is a very interesting approach and I wouldn't keep OSGi a backbone but
>>> one of the supported runtime (as spring-boot, microprofile or even
>>> javaee...oops jakartaee, why not?).
>>> So overall OSGi flavor would be a karaf 4 in a karaf 5 to illustrate the
>>> idea.
>>> Being able to aggregate runtimes in a single JVM has a great value but it
>>> must not come with all the build requirements (and prerequirements to tests
>>> for instance) so something lighter than OSGi, probably closer to
>>> tomcat/servlet classloading default model (parent with the "container",
>>> children with the apps) makes a lot of sense.
>>> I wouldn't call it karaf 5 (please dont do AMQ5-AMQ6 error), but as karaf
>>> is the industrialization of an OSGi runtime it makes sense to have an
>>> industrialization of a generic runtime, it is the next step IMO and I
>>> already envision the "merge" of a docker-compose/k8s recipe with 10
>>> uservices in a single JVM, financial department will love it and dev will
>>> keep doing what they want, everybody will be happy ;).
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>
>>>
>>> Le mer. 4 nov. 2020 à 08:52, Grzegorz Grzybek <gr...@gmail.com> a
>>> écrit :
>>>
>>>> śr., 4 lis 2020 o 08:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>>>>
>>>>> That’s a great feedback !
>>>>>
>>>>> Today, we are "challenged" by other approach. I still believe that we
>>>> have
>>>>> a great asset in the runtime ecosystem.
>>>>>
>>>>> 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.
>>>>> With François, I think we already identified some improvements patch
>>>>> (lighter/immutable runtime, tooling, …), but I would love to have
>>>> feedback
>>>>> from the community to drive the roadmap.
>>>>>
>>>>> Thanks Greg ! You made my day ;)
>>>>>
>>>> :)
>>>> I'll definitely think outside of OSGi box after I finish my current
>>>> assignment (work).
>>>>
>>>> regards
>>>> Grzegorz
>>>>
>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 4 nov. 2020 à 07:43, Grzegorz Grzybek <gr...@gmail.com> a
>>>> écrit
>>>>> :
>>>>>> śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>> napisał(a):
>>>>>>> What do you mean by "impossible" ? Removing OSGi from the picture, or
>>>>>>> thinking about Karaf future ? ;)
>>>>>>>
>>>>>> I meant I see OSGi everywhere and that's all I do for last 6+ years, so
>>>>>> it's hard for me to NOT think about OSGi ;)
>>>>>> If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
>>>>>>
>>>>>> regards
>>>>>> Grzegorz Grzybek
>>>>>>
>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a
>>>>> écrit
>>>>>>> :
>>>>>>>>> don’t think OSGi focus
>>>>>>>>>
>>>>>>>> For now it's impossible for me ;) Looks like I need some OSGi-REST...
>>>>> ;)
>>>>>>>> regards
>>>>>>>> Grzegorz
>>>>>>>>
>>>>>>>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>> napisał(a):
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Not yet, I’m working locally on changing the structure.
>>>>>>>>>
>>>>>>>>> And I don’t want to be influenced or influence for now ;)
>>>>>>>>>
>>>>>>>>> So, I would love your overall thinking in term of approach,
>>>> features,
>>>>>>>>> vision, and again generally speaking (don’t think OSGi focus, or one
>>>>>>>>> particular use case, more global).
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
>>>>>>> écrit
>>>>>>>>> :
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> Great news! Is this branch already available in Karaf's git repo?
>>>>>>>>>>
>>>>>>>>>> regards and stay safe!
>>>>>>>>>> Grzegorz Grzybek
>>>>>>>>>>
>>>>>>>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>>>> napisał(a):
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> François and I started to think about Karaf 5 and give an even
>>>>> modern
>>>>>>>>>>> flavor to Karaf, including potentially lot of refactoring and
>>>>> changes.
>>>>>>>>> We
>>>>>>>>>>> think it’s a must have in our patch to the "main modulith
>>>> runtime".
>>>>>>>>>>> Before sharing all details (some have been shared during my talk
>>>> at
>>>>>>>>>>> ApacheCon), we want to move forward on a PoC branch.
>>>>>>>>>>>
>>>>>>>>>>> However, we would love to have your inputs and thoughts (think
>>>> wide
>>>>>>> ;)).
>>>>>>>>>>> So, please, if you have ideas, comments, criticism ;), send me an
>>>>>>> email
>>>>>>>>>>> and I will reply and eventually include your points in the PoC.
>>>>>>>>>>>
>>>>>>>>>>> Thanks !
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>
>>>>>>>
>>>>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Francois Papon <fr...@openobject.fr>.
Agree and we have to focus on building the distribution and testing easily.
regards,
François
fpapon@apache.org
Le 04/11/2020 à 10:21, Jean-Baptiste Onofre a écrit :
> Changing the "perspective/cursor" with Karaf as "runtime backbone", where OSGi is a kind of runtime, at same level as spring-boot, micro profile, whatever, is actually very interesting.
>
> It could gives "perspective" to the project:
> - Karaf OSGi runtime
> - Karaf runtime manager
>
> I like the idea ;)
>
> Regards
> JB
>
>> Le 4 nov. 2020 à 09:39, Romain Manni-Bucau <rm...@gmail.com> a écrit :
>>
>> This is a very interesting approach and I wouldn't keep OSGi a backbone but
>> one of the supported runtime (as spring-boot, microprofile or even
>> javaee...oops jakartaee, why not?).
>> So overall OSGi flavor would be a karaf 4 in a karaf 5 to illustrate the
>> idea.
>> Being able to aggregate runtimes in a single JVM has a great value but it
>> must not come with all the build requirements (and prerequirements to tests
>> for instance) so something lighter than OSGi, probably closer to
>> tomcat/servlet classloading default model (parent with the "container",
>> children with the apps) makes a lot of sense.
>> I wouldn't call it karaf 5 (please dont do AMQ5-AMQ6 error), but as karaf
>> is the industrialization of an OSGi runtime it makes sense to have an
>> industrialization of a generic runtime, it is the next step IMO and I
>> already envision the "merge" of a docker-compose/k8s recipe with 10
>> uservices in a single JVM, financial department will love it and dev will
>> keep doing what they want, everybody will be happy ;).
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le mer. 4 nov. 2020 à 08:52, Grzegorz Grzybek <gr...@gmail.com> a
>> écrit :
>>
>>> śr., 4 lis 2020 o 08:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>>>
>>>> That’s a great feedback !
>>>>
>>>> Today, we are "challenged" by other approach. I still believe that we
>>> have
>>>> a great asset in the runtime ecosystem.
>>>>
>>>> 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.
>>>> With François, I think we already identified some improvements patch
>>>> (lighter/immutable runtime, tooling, …), but I would love to have
>>> feedback
>>>> from the community to drive the roadmap.
>>>>
>>>> Thanks Greg ! You made my day ;)
>>>>
>>> :)
>>> I'll definitely think outside of OSGi box after I finish my current
>>> assignment (work).
>>>
>>> regards
>>> Grzegorz
>>>
>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 4 nov. 2020 à 07:43, Grzegorz Grzybek <gr...@gmail.com> a
>>> écrit
>>>> :
>>>>> śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>> What do you mean by "impossible" ? Removing OSGi from the picture, or
>>>>>> thinking about Karaf future ? ;)
>>>>>>
>>>>> I meant I see OSGi everywhere and that's all I do for last 6+ years, so
>>>>> it's hard for me to NOT think about OSGi ;)
>>>>> If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a
>>>> écrit
>>>>>> :
>>>>>>>> don’t think OSGi focus
>>>>>>>>
>>>>>>> For now it's impossible for me ;) Looks like I need some OSGi-REST...
>>>> ;)
>>>>>>> regards
>>>>>>> Grzegorz
>>>>>>>
>>>>>>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>> napisał(a):
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Not yet, I’m working locally on changing the structure.
>>>>>>>>
>>>>>>>> And I don’t want to be influenced or influence for now ;)
>>>>>>>>
>>>>>>>> So, I would love your overall thinking in term of approach,
>>> features,
>>>>>>>> vision, and again generally speaking (don’t think OSGi focus, or one
>>>>>>>> particular use case, more global).
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
>>>>>> écrit
>>>>>>>> :
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> Great news! Is this branch already available in Karaf's git repo?
>>>>>>>>>
>>>>>>>>> regards and stay safe!
>>>>>>>>> Grzegorz Grzybek
>>>>>>>>>
>>>>>>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>>> napisał(a):
>>>>>>>>>> Hi guys,
>>>>>>>>>>
>>>>>>>>>> François and I started to think about Karaf 5 and give an even
>>>> modern
>>>>>>>>>> flavor to Karaf, including potentially lot of refactoring and
>>>> changes.
>>>>>>>> We
>>>>>>>>>> think it’s a must have in our patch to the "main modulith
>>> runtime".
>>>>>>>>>> Before sharing all details (some have been shared during my talk
>>> at
>>>>>>>>>> ApacheCon), we want to move forward on a PoC branch.
>>>>>>>>>>
>>>>>>>>>> However, we would love to have your inputs and thoughts (think
>>> wide
>>>>>> ;)).
>>>>>>>>>> So, please, if you have ideas, comments, criticism ;), send me an
>>>>>> email
>>>>>>>>>> and I will reply and eventually include your points in the PoC.
>>>>>>>>>>
>>>>>>>>>> Thanks !
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>
>>>>>>
>>>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Changing the "perspective/cursor" with Karaf as "runtime backbone", where OSGi is a kind of runtime, at same level as spring-boot, micro profile, whatever, is actually very interesting.
It could gives "perspective" to the project:
- Karaf OSGi runtime
- Karaf runtime manager
I like the idea ;)
Regards
JB
> Le 4 nov. 2020 à 09:39, Romain Manni-Bucau <rm...@gmail.com> a écrit :
>
> This is a very interesting approach and I wouldn't keep OSGi a backbone but
> one of the supported runtime (as spring-boot, microprofile or even
> javaee...oops jakartaee, why not?).
> So overall OSGi flavor would be a karaf 4 in a karaf 5 to illustrate the
> idea.
> Being able to aggregate runtimes in a single JVM has a great value but it
> must not come with all the build requirements (and prerequirements to tests
> for instance) so something lighter than OSGi, probably closer to
> tomcat/servlet classloading default model (parent with the "container",
> children with the apps) makes a lot of sense.
> I wouldn't call it karaf 5 (please dont do AMQ5-AMQ6 error), but as karaf
> is the industrialization of an OSGi runtime it makes sense to have an
> industrialization of a generic runtime, it is the next step IMO and I
> already envision the "merge" of a docker-compose/k8s recipe with 10
> uservices in a single JVM, financial department will love it and dev will
> keep doing what they want, everybody will be happy ;).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 4 nov. 2020 à 08:52, Grzegorz Grzybek <gr...@gmail.com> a
> écrit :
>
>> śr., 4 lis 2020 o 08:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>>
>>> That’s a great feedback !
>>>
>>> Today, we are "challenged" by other approach. I still believe that we
>> have
>>> a great asset in the runtime ecosystem.
>>>
>>> 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.
>>> With François, I think we already identified some improvements patch
>>> (lighter/immutable runtime, tooling, …), but I would love to have
>> feedback
>>> from the community to drive the roadmap.
>>>
>>> Thanks Greg ! You made my day ;)
>>>
>>
>> :)
>> I'll definitely think outside of OSGi box after I finish my current
>> assignment (work).
>>
>> regards
>> Grzegorz
>>
>>
>>> Regards
>>> JB
>>>
>>>> Le 4 nov. 2020 à 07:43, Grzegorz Grzybek <gr...@gmail.com> a
>> écrit
>>> :
>>>>
>>>> śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>> napisał(a):
>>>>
>>>>> What do you mean by "impossible" ? Removing OSGi from the picture, or
>>>>> thinking about Karaf future ? ;)
>>>>>
>>>>
>>>> I meant I see OSGi everywhere and that's all I do for last 6+ years, so
>>>> it's hard for me to NOT think about OSGi ;)
>>>> If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>>
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a
>>> écrit
>>>>> :
>>>>>>
>>>>>>>
>>>>>>> don’t think OSGi focus
>>>>>>>
>>>>>>
>>>>>> For now it's impossible for me ;) Looks like I need some OSGi-REST...
>>> ;)
>>>>>>
>>>>>> regards
>>>>>> Grzegorz
>>>>>>
>>>>>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>> napisał(a):
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Not yet, I’m working locally on changing the structure.
>>>>>>>
>>>>>>> And I don’t want to be influenced or influence for now ;)
>>>>>>>
>>>>>>> So, I would love your overall thinking in term of approach,
>> features,
>>>>>>> vision, and again generally speaking (don’t think OSGi focus, or one
>>>>>>> particular use case, more global).
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
>>>>> écrit
>>>>>>> :
>>>>>>>>
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> Great news! Is this branch already available in Karaf's git repo?
>>>>>>>>
>>>>>>>> regards and stay safe!
>>>>>>>> Grzegorz Grzybek
>>>>>>>>
>>>>>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>> napisał(a):
>>>>>>>>
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> François and I started to think about Karaf 5 and give an even
>>> modern
>>>>>>>>> flavor to Karaf, including potentially lot of refactoring and
>>> changes.
>>>>>>> We
>>>>>>>>> think it’s a must have in our patch to the "main modulith
>> runtime".
>>>>>>>>>
>>>>>>>>> Before sharing all details (some have been shared during my talk
>> at
>>>>>>>>> ApacheCon), we want to move forward on a PoC branch.
>>>>>>>>>
>>>>>>>>> However, we would love to have your inputs and thoughts (think
>> wide
>>>>> ;)).
>>>>>>>>>
>>>>>>>>> So, please, if you have ideas, comments, criticism ;), send me an
>>>>> email
>>>>>>>>> and I will reply and eventually include your points in the PoC.
>>>>>>>>>
>>>>>>>>> Thanks !
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Romain Manni-Bucau <rm...@gmail.com>.
This is a very interesting approach and I wouldn't keep OSGi a backbone but
one of the supported runtime (as spring-boot, microprofile or even
javaee...oops jakartaee, why not?).
So overall OSGi flavor would be a karaf 4 in a karaf 5 to illustrate the
idea.
Being able to aggregate runtimes in a single JVM has a great value but it
must not come with all the build requirements (and prerequirements to tests
for instance) so something lighter than OSGi, probably closer to
tomcat/servlet classloading default model (parent with the "container",
children with the apps) makes a lot of sense.
I wouldn't call it karaf 5 (please dont do AMQ5-AMQ6 error), but as karaf
is the industrialization of an OSGi runtime it makes sense to have an
industrialization of a generic runtime, it is the next step IMO and I
already envision the "merge" of a docker-compose/k8s recipe with 10
uservices in a single JVM, financial department will love it and dev will
keep doing what they want, everybody will be happy ;).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 nov. 2020 à 08:52, Grzegorz Grzybek <gr...@gmail.com> a
écrit :
> śr., 4 lis 2020 o 08:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
> > That’s a great feedback !
> >
> > Today, we are "challenged" by other approach. I still believe that we
> have
> > a great asset in the runtime ecosystem.
> >
> > 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.
> > With François, I think we already identified some improvements patch
> > (lighter/immutable runtime, tooling, …), but I would love to have
> feedback
> > from the community to drive the roadmap.
> >
> > Thanks Greg ! You made my day ;)
> >
>
> :)
> I'll definitely think outside of OSGi box after I finish my current
> assignment (work).
>
> regards
> Grzegorz
>
>
> > Regards
> > JB
> >
> > > Le 4 nov. 2020 à 07:43, Grzegorz Grzybek <gr...@gmail.com> a
> écrit
> > :
> > >
> > > śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net>
> > napisał(a):
> > >
> > >> What do you mean by "impossible" ? Removing OSGi from the picture, or
> > >> thinking about Karaf future ? ;)
> > >>
> > >
> > > I meant I see OSGi everywhere and that's all I do for last 6+ years, so
> > > it's hard for me to NOT think about OSGi ;)
> > > If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
> > >
> > > regards
> > > Grzegorz Grzybek
> > >
> > >
> > >>
> > >> Regards
> > >> JB
> > >>
> > >>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a
> > écrit
> > >> :
> > >>>
> > >>>>
> > >>>> don’t think OSGi focus
> > >>>>
> > >>>
> > >>> For now it's impossible for me ;) Looks like I need some OSGi-REST...
> > ;)
> > >>>
> > >>> regards
> > >>> Grzegorz
> > >>>
> > >>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
> > >> napisał(a):
> > >>>
> > >>>> Hi
> > >>>>
> > >>>> Not yet, I’m working locally on changing the structure.
> > >>>>
> > >>>> And I don’t want to be influenced or influence for now ;)
> > >>>>
> > >>>> So, I would love your overall thinking in term of approach,
> features,
> > >>>> vision, and again generally speaking (don’t think OSGi focus, or one
> > >>>> particular use case, more global).
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>>>
> > >>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
> > >> écrit
> > >>>> :
> > >>>>>
> > >>>>> Hello
> > >>>>>
> > >>>>> Great news! Is this branch already available in Karaf's git repo?
> > >>>>>
> > >>>>> regards and stay safe!
> > >>>>> Grzegorz Grzybek
> > >>>>>
> > >>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
> > >>>> napisał(a):
> > >>>>>
> > >>>>>> Hi guys,
> > >>>>>>
> > >>>>>> François and I started to think about Karaf 5 and give an even
> > modern
> > >>>>>> flavor to Karaf, including potentially lot of refactoring and
> > changes.
> > >>>> We
> > >>>>>> think it’s a must have in our patch to the "main modulith
> runtime".
> > >>>>>>
> > >>>>>> Before sharing all details (some have been shared during my talk
> at
> > >>>>>> ApacheCon), we want to move forward on a PoC branch.
> > >>>>>>
> > >>>>>> However, we would love to have your inputs and thoughts (think
> wide
> > >> ;)).
> > >>>>>>
> > >>>>>> So, please, if you have ideas, comments, criticism ;), send me an
> > >> email
> > >>>>>> and I will reply and eventually include your points in the PoC.
> > >>>>>>
> > >>>>>> Thanks !
> > >>>>>> Regards
> > >>>>>> JB
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Grzegorz Grzybek <gr...@gmail.com>.
śr., 4 lis 2020 o 08:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> That’s a great feedback !
>
> Today, we are "challenged" by other approach. I still believe that we have
> a great asset in the runtime ecosystem.
>
> 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.
> With François, I think we already identified some improvements patch
> (lighter/immutable runtime, tooling, …), but I would love to have feedback
> from the community to drive the roadmap.
>
> Thanks Greg ! You made my day ;)
>
:)
I'll definitely think outside of OSGi box after I finish my current
assignment (work).
regards
Grzegorz
> Regards
> JB
>
> > Le 4 nov. 2020 à 07:43, Grzegorz Grzybek <gr...@gmail.com> a écrit
> :
> >
> > śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> What do you mean by "impossible" ? Removing OSGi from the picture, or
> >> thinking about Karaf future ? ;)
> >>
> >
> > I meant I see OSGi everywhere and that's all I do for last 6+ years, so
> > it's hard for me to NOT think about OSGi ;)
> > If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >>
> >> Regards
> >> JB
> >>
> >>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a
> écrit
> >> :
> >>>
> >>>>
> >>>> don’t think OSGi focus
> >>>>
> >>>
> >>> For now it's impossible for me ;) Looks like I need some OSGi-REST...
> ;)
> >>>
> >>> regards
> >>> Grzegorz
> >>>
> >>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi
> >>>>
> >>>> Not yet, I’m working locally on changing the structure.
> >>>>
> >>>> And I don’t want to be influenced or influence for now ;)
> >>>>
> >>>> So, I would love your overall thinking in term of approach, features,
> >>>> vision, and again generally speaking (don’t think OSGi focus, or one
> >>>> particular use case, more global).
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
> >> écrit
> >>>> :
> >>>>>
> >>>>> Hello
> >>>>>
> >>>>> Great news! Is this branch already available in Karaf's git repo?
> >>>>>
> >>>>> regards and stay safe!
> >>>>> Grzegorz Grzybek
> >>>>>
> >>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>>> napisał(a):
> >>>>>
> >>>>>> Hi guys,
> >>>>>>
> >>>>>> François and I started to think about Karaf 5 and give an even
> modern
> >>>>>> flavor to Karaf, including potentially lot of refactoring and
> changes.
> >>>> We
> >>>>>> think it’s a must have in our patch to the "main modulith runtime".
> >>>>>>
> >>>>>> Before sharing all details (some have been shared during my talk at
> >>>>>> ApacheCon), we want to move forward on a PoC branch.
> >>>>>>
> >>>>>> However, we would love to have your inputs and thoughts (think wide
> >> ;)).
> >>>>>>
> >>>>>> So, please, if you have ideas, comments, criticism ;), send me an
> >> email
> >>>>>> and I will reply and eventually include your points in the PoC.
> >>>>>>
> >>>>>> Thanks !
> >>>>>> Regards
> >>>>>> JB
> >>>>
> >>>>
> >>
> >>
>
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Francois Papon <fr...@openobject.fr>.
Yep, first step can be providing some backend api for administration
like we already have in Cave.
regards,
François
fpapon@apache.org
Le 05/11/2020 à 14:11, Serge Huber a écrit :
> On Thu, Nov 5, 2020 at 5:50 AM Jean-Baptiste Onofre <jb...@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 <sh...@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 <ni...@hq.sk> wrote:
>>>
>>>> On 04/11/2020 20:29, Steinar Bang wrote:
>>>>>>>>>> Jean-Baptiste Onofre <jb...@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
>>>>
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Serge Huber <sh...@apache.org>.
On Thu, Nov 5, 2020 at 5:50 AM Jean-Baptiste Onofre <jb...@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 <sh...@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 <ni...@hq.sk> wrote:
> >
> >> On 04/11/2020 20:29, Steinar Bang wrote:
> >>>>>>>> Jean-Baptiste Onofre <jb...@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
> >>
>
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <sh...@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 <ni...@hq.sk> wrote:
>
>> On 04/11/2020 20:29, Steinar Bang wrote:
>>>>>>>> Jean-Baptiste Onofre <jb...@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
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Serge Huber <sh...@apache.org>.
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 <ni...@hq.sk> wrote:
> On 04/11/2020 20:29, Steinar Bang wrote:
> >>>>>> Jean-Baptiste Onofre <jb...@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
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <ni...@hq.sk> a écrit :
>
> On 04/11/2020 20:29, Steinar Bang wrote:
>>>>>>> Jean-Baptiste Onofre <jb...@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>
Re: Thinking about Karaf 5 modulith runtime
Posted by Robert Varga <ni...@hq.sk>.
On 04/11/2020 20:29, Steinar Bang wrote:
>>>>>> Jean-Baptiste Onofre <jb...@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
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Steinar,
Good feedback ;)
And clearly, we will "keep" karaf runtime philosophy (still on OSGi and improving it) and as Romain proposed a manager subproject.
Regards
JB
> Le 4 nov. 2020 à 20:29, Steinar Bang <sb...@dod.no> a écrit :
>
>>>>>> Jean-Baptiste Onofre <jb...@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...:-) )
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Jean-Baptiste Onofre <jb...@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...:-) )
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
That’s a great feedback !
Today, we are "challenged" by other approach. I still believe that we have a great asset in the runtime ecosystem.
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.
With François, I think we already identified some improvements patch (lighter/immutable runtime, tooling, …), but I would love to have feedback from the community to drive the roadmap.
Thanks Greg ! You made my day ;)
Regards
JB
> Le 4 nov. 2020 à 07:43, Grzegorz Grzybek <gr...@gmail.com> a écrit :
>
> śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> What do you mean by "impossible" ? Removing OSGi from the picture, or
>> thinking about Karaf future ? ;)
>>
>
> I meant I see OSGi everywhere and that's all I do for last 6+ years, so
> it's hard for me to NOT think about OSGi ;)
> If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
>
> regards
> Grzegorz Grzybek
>
>
>>
>> Regards
>> JB
>>
>>> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a écrit
>> :
>>>
>>>>
>>>> don’t think OSGi focus
>>>>
>>>
>>> For now it's impossible for me ;) Looks like I need some OSGi-REST... ;)
>>>
>>> regards
>>> Grzegorz
>>>
>>> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi
>>>>
>>>> Not yet, I’m working locally on changing the structure.
>>>>
>>>> And I don’t want to be influenced or influence for now ;)
>>>>
>>>> So, I would love your overall thinking in term of approach, features,
>>>> vision, and again generally speaking (don’t think OSGi focus, or one
>>>> particular use case, more global).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
>> écrit
>>>> :
>>>>>
>>>>> Hello
>>>>>
>>>>> Great news! Is this branch already available in Karaf's git repo?
>>>>>
>>>>> regards and stay safe!
>>>>> Grzegorz Grzybek
>>>>>
>>>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> François and I started to think about Karaf 5 and give an even modern
>>>>>> flavor to Karaf, including potentially lot of refactoring and changes.
>>>> We
>>>>>> think it’s a must have in our patch to the "main modulith runtime".
>>>>>>
>>>>>> Before sharing all details (some have been shared during my talk at
>>>>>> ApacheCon), we want to move forward on a PoC branch.
>>>>>>
>>>>>> However, we would love to have your inputs and thoughts (think wide
>> ;)).
>>>>>>
>>>>>> So, please, if you have ideas, comments, criticism ;), send me an
>> email
>>>>>> and I will reply and eventually include your points in the PoC.
>>>>>>
>>>>>> Thanks !
>>>>>> Regards
>>>>>> JB
>>>>
>>>>
>>
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Grzegorz Grzybek <gr...@gmail.com>.
śr., 4 lis 2020 o 07:41 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> What do you mean by "impossible" ? Removing OSGi from the picture, or
> thinking about Karaf future ? ;)
>
I meant I see OSGi everywhere and that's all I do for last 6+ years, so
it's hard for me to NOT think about OSGi ;)
If I was asked to help shaping Karaf 5, I'd still think OSGi-first...
regards
Grzegorz Grzybek
>
> Regards
> JB
>
> > Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a écrit
> :
> >
> >>
> >> don’t think OSGi focus
> >>
> >
> > For now it's impossible for me ;) Looks like I need some OSGi-REST... ;)
> >
> > regards
> > Grzegorz
> >
> > śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi
> >>
> >> Not yet, I’m working locally on changing the structure.
> >>
> >> And I don’t want to be influenced or influence for now ;)
> >>
> >> So, I would love your overall thinking in term of approach, features,
> >> vision, and again generally speaking (don’t think OSGi focus, or one
> >> particular use case, more global).
> >>
> >> Regards
> >> JB
> >>
> >>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a
> écrit
> >> :
> >>>
> >>> Hello
> >>>
> >>> Great news! Is this branch already available in Karaf's git repo?
> >>>
> >>> regards and stay safe!
> >>> Grzegorz Grzybek
> >>>
> >>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi guys,
> >>>>
> >>>> François and I started to think about Karaf 5 and give an even modern
> >>>> flavor to Karaf, including potentially lot of refactoring and changes.
> >> We
> >>>> think it’s a must have in our patch to the "main modulith runtime".
> >>>>
> >>>> Before sharing all details (some have been shared during my talk at
> >>>> ApacheCon), we want to move forward on a PoC branch.
> >>>>
> >>>> However, we would love to have your inputs and thoughts (think wide
> ;)).
> >>>>
> >>>> So, please, if you have ideas, comments, criticism ;), send me an
> email
> >>>> and I will reply and eventually include your points in the PoC.
> >>>>
> >>>> Thanks !
> >>>> Regards
> >>>> JB
> >>
> >>
>
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
What do you mean by "impossible" ? Removing OSGi from the picture, or thinking about Karaf future ? ;)
Regards
JB
> Le 4 nov. 2020 à 06:27, Grzegorz Grzybek <gr...@gmail.com> a écrit :
>
>>
>> don’t think OSGi focus
>>
>
> For now it's impossible for me ;) Looks like I need some OSGi-REST... ;)
>
> regards
> Grzegorz
>
> śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi
>>
>> Not yet, I’m working locally on changing the structure.
>>
>> And I don’t want to be influenced or influence for now ;)
>>
>> So, I would love your overall thinking in term of approach, features,
>> vision, and again generally speaking (don’t think OSGi focus, or one
>> particular use case, more global).
>>
>> Regards
>> JB
>>
>>> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a écrit
>> :
>>>
>>> Hello
>>>
>>> Great news! Is this branch already available in Karaf's git repo?
>>>
>>> regards and stay safe!
>>> Grzegorz Grzybek
>>>
>>> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi guys,
>>>>
>>>> François and I started to think about Karaf 5 and give an even modern
>>>> flavor to Karaf, including potentially lot of refactoring and changes.
>> We
>>>> think it’s a must have in our patch to the "main modulith runtime".
>>>>
>>>> Before sharing all details (some have been shared during my talk at
>>>> ApacheCon), we want to move forward on a PoC branch.
>>>>
>>>> However, we would love to have your inputs and thoughts (think wide ;)).
>>>>
>>>> So, please, if you have ideas, comments, criticism ;), send me an email
>>>> and I will reply and eventually include your points in the PoC.
>>>>
>>>> Thanks !
>>>> Regards
>>>> JB
>>
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Grzegorz Grzybek <gr...@gmail.com>.
>
> don’t think OSGi focus
>
For now it's impossible for me ;) Looks like I need some OSGi-REST... ;)
regards
Grzegorz
śr., 4 lis 2020 o 06:16 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi
>
> Not yet, I’m working locally on changing the structure.
>
> And I don’t want to be influenced or influence for now ;)
>
> So, I would love your overall thinking in term of approach, features,
> vision, and again generally speaking (don’t think OSGi focus, or one
> particular use case, more global).
>
> Regards
> JB
>
> > Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a écrit
> :
> >
> > Hello
> >
> > Great news! Is this branch already available in Karaf's git repo?
> >
> > regards and stay safe!
> > Grzegorz Grzybek
> >
> > śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi guys,
> >>
> >> François and I started to think about Karaf 5 and give an even modern
> >> flavor to Karaf, including potentially lot of refactoring and changes.
> We
> >> think it’s a must have in our patch to the "main modulith runtime".
> >>
> >> Before sharing all details (some have been shared during my talk at
> >> ApacheCon), we want to move forward on a PoC branch.
> >>
> >> However, we would love to have your inputs and thoughts (think wide ;)).
> >>
> >> So, please, if you have ideas, comments, criticism ;), send me an email
> >> and I will reply and eventually include your points in the PoC.
> >>
> >> Thanks !
> >> Regards
> >> JB
>
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi
Not yet, I’m working locally on changing the structure.
And I don’t want to be influenced or influence for now ;)
So, I would love your overall thinking in term of approach, features, vision, and again generally speaking (don’t think OSGi focus, or one particular use case, more global).
Regards
JB
> Le 4 nov. 2020 à 06:09, Grzegorz Grzybek <gr...@gmail.com> a écrit :
>
> Hello
>
> Great news! Is this branch already available in Karaf's git repo?
>
> regards and stay safe!
> Grzegorz Grzybek
>
> śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi guys,
>>
>> François and I started to think about Karaf 5 and give an even modern
>> flavor to Karaf, including potentially lot of refactoring and changes. We
>> think it’s a must have in our patch to the "main modulith runtime".
>>
>> Before sharing all details (some have been shared during my talk at
>> ApacheCon), we want to move forward on a PoC branch.
>>
>> However, we would love to have your inputs and thoughts (think wide ;)).
>>
>> So, please, if you have ideas, comments, criticism ;), send me an email
>> and I will reply and eventually include your points in the PoC.
>>
>> Thanks !
>> Regards
>> JB
Re: Thinking about Karaf 5 modulith runtime
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Great news! Is this branch already available in Karaf's git repo?
regards and stay safe!
Grzegorz Grzybek
śr., 4 lis 2020 o 05:59 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi guys,
>
> François and I started to think about Karaf 5 and give an even modern
> flavor to Karaf, including potentially lot of refactoring and changes. We
> think it’s a must have in our patch to the "main modulith runtime".
>
> Before sharing all details (some have been shared during my talk at
> ApacheCon), we want to move forward on a PoC branch.
>
> However, we would love to have your inputs and thoughts (think wide ;)).
>
> So, please, if you have ideas, comments, criticism ;), send me an email
> and I will reply and eventually include your points in the PoC.
>
> Thanks !
> Regards
> JB
Re: Thinking about Karaf 5 modulith runtime
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hallo,
want to contribute to the discussion as well. We recently migrated a very large codebase from JbossOSGi to Karaf. The main reason was that we already had invested a lot into OSGi and that with Karaf you can more selectively expand platform functions.
For the future of Karaf this means: it should still be open to different framework and libraries, it can still benefit from OSGi. Some newer frameworks like CDI and Micro Profile should be present.
It’s unlikely that spring boot or quarks users would switch, but if you can use spring or cdi then there is a change some people would consider Karaf. The biggest stream of users is expected to come from the JavaEE camp, if they can keep using those APIs and also get many of the JakartaEE implementations Karaf would be a good runtime for at least those...
Having said that, working on the footprint of Karaf is certainly a good goal, as well as support for deploying a collection of libraries without the need to wrap all in bundles would be starter friendly (but in the end it’s a non issue for us).
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Jean-Baptiste Onofre <jb...@nanthrax.net>
Gesendet: Monday, November 9, 2020 6:20:26 AM
An: dev@karaf.apache.org <de...@karaf.apache.org>
Betreff: Re: Thinking about Karaf 5 modulith runtime
Hi Lukasz,
And thanks for your feedback. I think it’s a fair feedback about the current situation.
I think Karaf is one thing and OSGi is another one (for a project perspective).
So, we can drive Karaf roadmap to something different if it makes sense.
Remember, first ServiceMix version was Spring focus before moving to OSGi.
So the other way around can be true.
We can use OSGi internally, and provide some user facing different approaches.
Karaf devx/tool is the first thing to achieve: improve developer experience, simplify test and runtime assembly.
I agree that we don’t have the marketing power of Pivotal (we are "real" open source project after all ;)) and we don’t have a single company providing marketing power.
I think we have two personas:
1. People already using Karaf, and for them, we have to improve and provide a better runtime generally speaking for sure
2. People not using Karaf, using spring boot, cdi, whatever. I doubt we will convince them to switch to Karaf with another programming framework. The purpose is more to try to attract them with a runtime directly supporting their applications but providing adhoc features out of the box for them (the purpose of a runtime).
That’s what I have in mind for now: improve (thanks for devx and other new features), and attract.
Regards
JB
> Le 9 nov. 2020 à 02:42, Łukasz Dywicki <lu...@code-house.org> a écrit :
>
> I am quite late for this discussion and haven't watched your ApacheCon
> talk, hence pardon my points if they're wrong.
>
> Reorganizing code base is highly appreciated since karaf source tree
> grew since 2.x without any major changes in directory structure.
> Till these days it is confusing to me where "enterprise" features come
> from (in terms of maven POM) and where "framework-static" lives.
> I do believe that improving tooling and docs will help a lot. I keep
> getting into troubles with tooling every-so-often.
>
>
> The question where Karaf should or could go.. that's quite difficult to
> answer. From what I see OSGi marketplace is shrinking year-to-year and
> recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
> personal opinion, result of deep organization failure. It simply did not
> attract enough of people to use, promote and pay for their certification.
> Beside Eclipse IDE there are still many products which are based on OSGi
> itself. Yet thanks to above move OSGi and Eclipse are closer than
> before making all black PR of Eclipse IDE directly transferable to
> entire OSGi ecosystem.
>
> In curium stances we have we need to be rationale about whether we can
> or can not fight for "microservices" term any more and if any major
> changes will move us ahead.
> I doubt if positioning Apache Karaf as an alternative to Spring Boot or
> other tools in this category will help. I think they fight for slightly
> different projects than we ever did. Karaf always been middleware
> platform and not application framework. Making apps on top of it is
> doable, but probably done mainly by people who used runtime already and
> didn't want to complicate deployment. We're pretty far from being first
> choice for application runtime as there are quite many alternatives.
> Most of applications will not even feel benefit of OSGi.
> We simply have no marketing power to fight over media buzz sustained by
> other (especially Spring) communities. Most importantly we have no man
> power to keep up all satellite projects around. The nature of
> Spring/Pivotal development is based on number of paid developers and
> consultants who actively contribute to development of their ecosystem
> components. Above all they keep doing technical sales promising fast
> delivery of projects in numbers which we probably never heard of.
> I know that comparing number of stars on github is worst metric to be
> used, yet we have 505 starts whereas boot have 51k. *90 times more*.
>
> I am afraid we have none of above prerequisities (manpower, marketing,
> money). All efforts which we depend upon are distributed around multiple
> top level Apache projects (CXF, Camel, AMQ) and surroundings such as OPS4J.
> We can't get everyone around working on Karaf/OSGi integration, simply
> because focus of other communities is somewhere else. This means we will
> have to ship these components and later maintain integration. Shutdown
> of Apache Geronimo shows that application server era is over and what I
> hear between sentences is re-birth of OSGi enabled application platform
> which Apache Geronimo once promised to become.
> Again, I don't think that switching to microprofile will help us much
> cause there are existing projects such as Apache TomEE who do that
> already with help of CDI. What is our advantage over their? OSGi which
> failed to attract people over past decade? Or smaller footprint in era
> of GraalVM?
>
> Please hear me out. I am not saying that easing adoption of OSGi and
> Karaf is wrong. I am just saying that its gonna be very difficult to
> promote it and get other people engaged. So better focus on community we
> have, serve their needs and simplify their life. If we solve their
> trouble and do it in reliable way we have chance to survive. Maybe
> adoptions will continue to grow and will bring more people to help
> moving forward.
>
> Kind regards,
> Łukasz
> --
> Code-House
> http://code-house.org
>
>
> On 04.11.2020 05:59, Jean-Baptiste Onofre wrote:
>> Hi guys,
>>
>> François and I started to think about Karaf 5 and give an even modern flavor to Karaf, including potentially lot of refactoring and changes. We think it’s a must have in our patch to the "main modulith runtime".
>>
>> Before sharing all details (some have been shared during my talk at ApacheCon), we want to move forward on a PoC branch.
>>
>> However, we would love to have your inputs and thoughts (think wide ;)).
>>
>> So, please, if you have ideas, comments, criticism ;), send me an email and I will reply and eventually include your points in the PoC.
>>
>> Thanks !
>> Regards
>> JB
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Great discussion!
Even if I work with OSGi for a long time, I'd like to avoid expressing
clearly how I see the future. I simply ... don't know and don't feel like I
should decide or even help to decide. I was always happiest working on
something that's used by someone, but somehow missing
functionality/stability. I love fixing deadlocks, memory leaks, performance
issues in whatever technology. I joined Red Hat a short time after I ...
was helping with CORBA binding for CXF.
The same is with OSGi - while surrounded with rants about this technology
("why this bundle refreshes?", "why this bundle fails with ... «it is
exposed to package xxx via two dependency chains»?", ...) I learned to like
it and enjoyed the time refactoring Pax Logging, adding Feature override
support to Karaf or now, refactoring (unfinished yet) Pax Web.
Seeing how Quarkus works and how application servers died (slower or
faster) over time I know that something has changed. OSGi promise of a
single JVM process with dynamically added/removed/changed processes is no
longer attractive when starting a new process is even faster now...
I like Karaf, I like its shell, I like the features I just don't know how
the future looks like. So I'm happy to help with low level issues - whether
these are bundle wirings or thread deadlocks. I trust you guys about where
you'll lead Karaf ;)
kind regards
Grzegorz Grzybek
pon., 9 lis 2020 o 08:40 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Absolutely, I fully agree !
>
> I see the Karaf future as launcher (actually, it’s better than runtime)
> and adhoc features.
>
> That’s the point of:
> - Karaf OSGi runtime is one subproject
> - Karaf Launcher as multiruntime launcher.
>
> And also agree to move forward fast ;)
>
> Thanks !
> Regards
> JB
>
> > Le 9 nov. 2020 à 08:35, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
> >
> > To enhance what JB says there are other things to consider I think:
> >
> > 1. There is space for a "docker destructor" (everybody does a
> microservice
> > to read a config file these days, when the company hosting it in the
> cloud
> > checks the costs it realizes it can be reduced by at last 10 generally,
> > without perf or dev/responsabilities impact - what uservices are for).
> Here
> > the new subproject makes a lot of sense for me
> > 2. If you look the landscape today you have the choice between spring
> boot
> > or microprofile (or play but point is the same), ie a single company
> > project (yes MP is that as well since quarkus killed others in terms of
> > communication and even without respecting any of the spec it promotes, it
> > wins the $$ fight as expected, in particular since IBM and RH merged).
> > Indeed cloud makes vendor locking less important, but mainly for hosted
> > service, not for dev when the company have to maintain its project. OSGi
> > was an alternative until it goes to Eclipse (I agree it looks like a
> > cemetery) and moreover the overlayer OSGi specs adds to
> Jakarta/underlying
> > specs (often breaking part of them) + the build constraints it implies
> does
> > not help - here Winegrower helps a lot though without loosing OSGi libs.
> So
> > overall, if you are a company and want to bet on the future in terms of
> > stack you don't have the choice anymore. At Geronimo we proposed to
> "fork"
> > our Microprofile implementations to have a vendor neutral stack but seems
> > dev are far from stack decisions and therefore it will not help much.
> >
> > All that to say that 1 can be an interesting future for karaf and maybe
> in
> > some year become the TLP and Karaf the subproject. I also think it is the
> > moment to think about it to not wait for Karaf to have to go to attic.
> > Karaf is a launcher (main) + some tools (features mainly), it does not
> have
> > to leave that space, it will just leave the scope of this space IMHO.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 9 nov. 2020 à 06:20, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> > écrit :
> >
> >> Hi Lukasz,
> >>
> >> And thanks for your feedback. I think it’s a fair feedback about the
> >> current situation.
> >>
> >> I think Karaf is one thing and OSGi is another one (for a project
> >> perspective).
> >> So, we can drive Karaf roadmap to something different if it makes sense.
> >>
> >> Remember, first ServiceMix version was Spring focus before moving to
> OSGi.
> >> So the other way around can be true.
> >>
> >> We can use OSGi internally, and provide some user facing different
> >> approaches.
> >>
> >> Karaf devx/tool is the first thing to achieve: improve developer
> >> experience, simplify test and runtime assembly.
> >>
> >> I agree that we don’t have the marketing power of Pivotal (we are "real"
> >> open source project after all ;)) and we don’t have a single company
> >> providing marketing power.
> >>
> >> I think we have two personas:
> >>
> >> 1. People already using Karaf, and for them, we have to improve and
> >> provide a better runtime generally speaking for sure
> >> 2. People not using Karaf, using spring boot, cdi, whatever. I doubt we
> >> will convince them to switch to Karaf with another programming
> framework.
> >> The purpose is more to try to attract them with a runtime directly
> >> supporting their applications but providing adhoc features out of the
> box
> >> for them (the purpose of a runtime).
> >>
> >> That’s what I have in mind for now: improve (thanks for devx and other
> new
> >> features), and attract.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 9 nov. 2020 à 02:42, Łukasz Dywicki <lu...@code-house.org> a écrit :
> >>>
> >>> I am quite late for this discussion and haven't watched your ApacheCon
> >>> talk, hence pardon my points if they're wrong.
> >>>
> >>> Reorganizing code base is highly appreciated since karaf source tree
> >>> grew since 2.x without any major changes in directory structure.
> >>> Till these days it is confusing to me where "enterprise" features come
> >>> from (in terms of maven POM) and where "framework-static" lives.
> >>> I do believe that improving tooling and docs will help a lot. I keep
> >>> getting into troubles with tooling every-so-often.
> >>>
> >>>
> >>> The question where Karaf should or could go.. that's quite difficult to
> >>> answer. From what I see OSGi marketplace is shrinking year-to-year and
> >>> recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
> >>> personal opinion, result of deep organization failure. It simply did
> not
> >>> attract enough of people to use, promote and pay for their
> certification.
> >>> Beside Eclipse IDE there are still many products which are based on
> OSGi
> >>> itself. Yet thanks to above move OSGi and Eclipse are closer than
> >>> before making all black PR of Eclipse IDE directly transferable to
> >>> entire OSGi ecosystem.
> >>>
> >>> In curium stances we have we need to be rationale about whether we can
> >>> or can not fight for "microservices" term any more and if any major
> >>> changes will move us ahead.
> >>> I doubt if positioning Apache Karaf as an alternative to Spring Boot or
> >>> other tools in this category will help. I think they fight for slightly
> >>> different projects than we ever did. Karaf always been middleware
> >>> platform and not application framework. Making apps on top of it is
> >>> doable, but probably done mainly by people who used runtime already and
> >>> didn't want to complicate deployment. We're pretty far from being first
> >>> choice for application runtime as there are quite many alternatives.
> >>> Most of applications will not even feel benefit of OSGi.
> >>> We simply have no marketing power to fight over media buzz sustained by
> >>> other (especially Spring) communities. Most importantly we have no man
> >>> power to keep up all satellite projects around. The nature of
> >>> Spring/Pivotal development is based on number of paid developers and
> >>> consultants who actively contribute to development of their ecosystem
> >>> components. Above all they keep doing technical sales promising fast
> >>> delivery of projects in numbers which we probably never heard of.
> >>> I know that comparing number of stars on github is worst metric to be
> >>> used, yet we have 505 starts whereas boot have 51k. *90 times more*.
> >>>
> >>> I am afraid we have none of above prerequisities (manpower, marketing,
> >>> money). All efforts which we depend upon are distributed around
> multiple
> >>> top level Apache projects (CXF, Camel, AMQ) and surroundings such as
> >> OPS4J.
> >>> We can't get everyone around working on Karaf/OSGi integration, simply
> >>> because focus of other communities is somewhere else. This means we
> will
> >>> have to ship these components and later maintain integration. Shutdown
> >>> of Apache Geronimo shows that application server era is over and what I
> >>> hear between sentences is re-birth of OSGi enabled application platform
> >>> which Apache Geronimo once promised to become.
> >>> Again, I don't think that switching to microprofile will help us much
> >>> cause there are existing projects such as Apache TomEE who do that
> >>> already with help of CDI. What is our advantage over their? OSGi which
> >>> failed to attract people over past decade? Or smaller footprint in era
> >>> of GraalVM?
> >>>
> >>> Please hear me out. I am not saying that easing adoption of OSGi and
> >>> Karaf is wrong. I am just saying that its gonna be very difficult to
> >>> promote it and get other people engaged. So better focus on community
> we
> >>> have, serve their needs and simplify their life. If we solve their
> >>> trouble and do it in reliable way we have chance to survive. Maybe
> >>> adoptions will continue to grow and will bring more people to help
> >>> moving forward.
> >>>
> >>> Kind regards,
> >>> Łukasz
> >>> --
> >>> Code-House
> >>> http://code-house.org
> >>>
> >>>
> >>> On 04.11.2020 05:59, Jean-Baptiste Onofre wrote:
> >>>> Hi guys,
> >>>>
> >>>> François and I started to think about Karaf 5 and give an even modern
> >> flavor to Karaf, including potentially lot of refactoring and changes.
> We
> >> think it’s a must have in our patch to the "main modulith runtime".
> >>>>
> >>>> Before sharing all details (some have been shared during my talk at
> >> ApacheCon), we want to move forward on a PoC branch.
> >>>>
> >>>> However, we would love to have your inputs and thoughts (think wide
> ;)).
> >>>>
> >>>> So, please, if you have ideas, comments, criticism ;), send me an
> email
> >> and I will reply and eventually include your points in the PoC.
> >>>>
> >>>> Thanks !
> >>>> Regards
> >>>> JB
> >>>>
> >>
> >>
>
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Absolutely, I fully agree !
I see the Karaf future as launcher (actually, it’s better than runtime) and adhoc features.
That’s the point of:
- Karaf OSGi runtime is one subproject
- Karaf Launcher as multiruntime launcher.
And also agree to move forward fast ;)
Thanks !
Regards
JB
> Le 9 nov. 2020 à 08:35, Romain Manni-Bucau <rm...@gmail.com> a écrit :
>
> To enhance what JB says there are other things to consider I think:
>
> 1. There is space for a "docker destructor" (everybody does a microservice
> to read a config file these days, when the company hosting it in the cloud
> checks the costs it realizes it can be reduced by at last 10 generally,
> without perf or dev/responsabilities impact - what uservices are for). Here
> the new subproject makes a lot of sense for me
> 2. If you look the landscape today you have the choice between spring boot
> or microprofile (or play but point is the same), ie a single company
> project (yes MP is that as well since quarkus killed others in terms of
> communication and even without respecting any of the spec it promotes, it
> wins the $$ fight as expected, in particular since IBM and RH merged).
> Indeed cloud makes vendor locking less important, but mainly for hosted
> service, not for dev when the company have to maintain its project. OSGi
> was an alternative until it goes to Eclipse (I agree it looks like a
> cemetery) and moreover the overlayer OSGi specs adds to Jakarta/underlying
> specs (often breaking part of them) + the build constraints it implies does
> not help - here Winegrower helps a lot though without loosing OSGi libs. So
> overall, if you are a company and want to bet on the future in terms of
> stack you don't have the choice anymore. At Geronimo we proposed to "fork"
> our Microprofile implementations to have a vendor neutral stack but seems
> dev are far from stack decisions and therefore it will not help much.
>
> All that to say that 1 can be an interesting future for karaf and maybe in
> some year become the TLP and Karaf the subproject. I also think it is the
> moment to think about it to not wait for Karaf to have to go to attic.
> Karaf is a launcher (main) + some tools (features mainly), it does not have
> to leave that space, it will just leave the scope of this space IMHO.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le lun. 9 nov. 2020 à 06:20, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> écrit :
>
>> Hi Lukasz,
>>
>> And thanks for your feedback. I think it’s a fair feedback about the
>> current situation.
>>
>> I think Karaf is one thing and OSGi is another one (for a project
>> perspective).
>> So, we can drive Karaf roadmap to something different if it makes sense.
>>
>> Remember, first ServiceMix version was Spring focus before moving to OSGi.
>> So the other way around can be true.
>>
>> We can use OSGi internally, and provide some user facing different
>> approaches.
>>
>> Karaf devx/tool is the first thing to achieve: improve developer
>> experience, simplify test and runtime assembly.
>>
>> I agree that we don’t have the marketing power of Pivotal (we are "real"
>> open source project after all ;)) and we don’t have a single company
>> providing marketing power.
>>
>> I think we have two personas:
>>
>> 1. People already using Karaf, and for them, we have to improve and
>> provide a better runtime generally speaking for sure
>> 2. People not using Karaf, using spring boot, cdi, whatever. I doubt we
>> will convince them to switch to Karaf with another programming framework.
>> The purpose is more to try to attract them with a runtime directly
>> supporting their applications but providing adhoc features out of the box
>> for them (the purpose of a runtime).
>>
>> That’s what I have in mind for now: improve (thanks for devx and other new
>> features), and attract.
>>
>> Regards
>> JB
>>
>>> Le 9 nov. 2020 à 02:42, Łukasz Dywicki <lu...@code-house.org> a écrit :
>>>
>>> I am quite late for this discussion and haven't watched your ApacheCon
>>> talk, hence pardon my points if they're wrong.
>>>
>>> Reorganizing code base is highly appreciated since karaf source tree
>>> grew since 2.x without any major changes in directory structure.
>>> Till these days it is confusing to me where "enterprise" features come
>>> from (in terms of maven POM) and where "framework-static" lives.
>>> I do believe that improving tooling and docs will help a lot. I keep
>>> getting into troubles with tooling every-so-often.
>>>
>>>
>>> The question where Karaf should or could go.. that's quite difficult to
>>> answer. From what I see OSGi marketplace is shrinking year-to-year and
>>> recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
>>> personal opinion, result of deep organization failure. It simply did not
>>> attract enough of people to use, promote and pay for their certification.
>>> Beside Eclipse IDE there are still many products which are based on OSGi
>>> itself. Yet thanks to above move OSGi and Eclipse are closer than
>>> before making all black PR of Eclipse IDE directly transferable to
>>> entire OSGi ecosystem.
>>>
>>> In curium stances we have we need to be rationale about whether we can
>>> or can not fight for "microservices" term any more and if any major
>>> changes will move us ahead.
>>> I doubt if positioning Apache Karaf as an alternative to Spring Boot or
>>> other tools in this category will help. I think they fight for slightly
>>> different projects than we ever did. Karaf always been middleware
>>> platform and not application framework. Making apps on top of it is
>>> doable, but probably done mainly by people who used runtime already and
>>> didn't want to complicate deployment. We're pretty far from being first
>>> choice for application runtime as there are quite many alternatives.
>>> Most of applications will not even feel benefit of OSGi.
>>> We simply have no marketing power to fight over media buzz sustained by
>>> other (especially Spring) communities. Most importantly we have no man
>>> power to keep up all satellite projects around. The nature of
>>> Spring/Pivotal development is based on number of paid developers and
>>> consultants who actively contribute to development of their ecosystem
>>> components. Above all they keep doing technical sales promising fast
>>> delivery of projects in numbers which we probably never heard of.
>>> I know that comparing number of stars on github is worst metric to be
>>> used, yet we have 505 starts whereas boot have 51k. *90 times more*.
>>>
>>> I am afraid we have none of above prerequisities (manpower, marketing,
>>> money). All efforts which we depend upon are distributed around multiple
>>> top level Apache projects (CXF, Camel, AMQ) and surroundings such as
>> OPS4J.
>>> We can't get everyone around working on Karaf/OSGi integration, simply
>>> because focus of other communities is somewhere else. This means we will
>>> have to ship these components and later maintain integration. Shutdown
>>> of Apache Geronimo shows that application server era is over and what I
>>> hear between sentences is re-birth of OSGi enabled application platform
>>> which Apache Geronimo once promised to become.
>>> Again, I don't think that switching to microprofile will help us much
>>> cause there are existing projects such as Apache TomEE who do that
>>> already with help of CDI. What is our advantage over their? OSGi which
>>> failed to attract people over past decade? Or smaller footprint in era
>>> of GraalVM?
>>>
>>> Please hear me out. I am not saying that easing adoption of OSGi and
>>> Karaf is wrong. I am just saying that its gonna be very difficult to
>>> promote it and get other people engaged. So better focus on community we
>>> have, serve their needs and simplify their life. If we solve their
>>> trouble and do it in reliable way we have chance to survive. Maybe
>>> adoptions will continue to grow and will bring more people to help
>>> moving forward.
>>>
>>> Kind regards,
>>> Łukasz
>>> --
>>> Code-House
>>> http://code-house.org
>>>
>>>
>>> On 04.11.2020 05:59, Jean-Baptiste Onofre wrote:
>>>> Hi guys,
>>>>
>>>> François and I started to think about Karaf 5 and give an even modern
>> flavor to Karaf, including potentially lot of refactoring and changes. We
>> think it’s a must have in our patch to the "main modulith runtime".
>>>>
>>>> Before sharing all details (some have been shared during my talk at
>> ApacheCon), we want to move forward on a PoC branch.
>>>>
>>>> However, we would love to have your inputs and thoughts (think wide ;)).
>>>>
>>>> So, please, if you have ideas, comments, criticism ;), send me an email
>> and I will reply and eventually include your points in the PoC.
>>>>
>>>> Thanks !
>>>> Regards
>>>> JB
>>>>
>>
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Romain Manni-Bucau <rm...@gmail.com>.
To enhance what JB says there are other things to consider I think:
1. There is space for a "docker destructor" (everybody does a microservice
to read a config file these days, when the company hosting it in the cloud
checks the costs it realizes it can be reduced by at last 10 generally,
without perf or dev/responsabilities impact - what uservices are for). Here
the new subproject makes a lot of sense for me
2. If you look the landscape today you have the choice between spring boot
or microprofile (or play but point is the same), ie a single company
project (yes MP is that as well since quarkus killed others in terms of
communication and even without respecting any of the spec it promotes, it
wins the $$ fight as expected, in particular since IBM and RH merged).
Indeed cloud makes vendor locking less important, but mainly for hosted
service, not for dev when the company have to maintain its project. OSGi
was an alternative until it goes to Eclipse (I agree it looks like a
cemetery) and moreover the overlayer OSGi specs adds to Jakarta/underlying
specs (often breaking part of them) + the build constraints it implies does
not help - here Winegrower helps a lot though without loosing OSGi libs. So
overall, if you are a company and want to bet on the future in terms of
stack you don't have the choice anymore. At Geronimo we proposed to "fork"
our Microprofile implementations to have a vendor neutral stack but seems
dev are far from stack decisions and therefore it will not help much.
All that to say that 1 can be an interesting future for karaf and maybe in
some year become the TLP and Karaf the subproject. I also think it is the
moment to think about it to not wait for Karaf to have to go to attic.
Karaf is a launcher (main) + some tools (features mainly), it does not have
to leave that space, it will just leave the scope of this space IMHO.
Hope it makes sense.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 9 nov. 2020 à 06:20, Jean-Baptiste Onofre <jb...@nanthrax.net> a
écrit :
> Hi Lukasz,
>
> And thanks for your feedback. I think it’s a fair feedback about the
> current situation.
>
> I think Karaf is one thing and OSGi is another one (for a project
> perspective).
> So, we can drive Karaf roadmap to something different if it makes sense.
>
> Remember, first ServiceMix version was Spring focus before moving to OSGi.
> So the other way around can be true.
>
> We can use OSGi internally, and provide some user facing different
> approaches.
>
> Karaf devx/tool is the first thing to achieve: improve developer
> experience, simplify test and runtime assembly.
>
> I agree that we don’t have the marketing power of Pivotal (we are "real"
> open source project after all ;)) and we don’t have a single company
> providing marketing power.
>
> I think we have two personas:
>
> 1. People already using Karaf, and for them, we have to improve and
> provide a better runtime generally speaking for sure
> 2. People not using Karaf, using spring boot, cdi, whatever. I doubt we
> will convince them to switch to Karaf with another programming framework.
> The purpose is more to try to attract them with a runtime directly
> supporting their applications but providing adhoc features out of the box
> for them (the purpose of a runtime).
>
> That’s what I have in mind for now: improve (thanks for devx and other new
> features), and attract.
>
> Regards
> JB
>
> > Le 9 nov. 2020 à 02:42, Łukasz Dywicki <lu...@code-house.org> a écrit :
> >
> > I am quite late for this discussion and haven't watched your ApacheCon
> > talk, hence pardon my points if they're wrong.
> >
> > Reorganizing code base is highly appreciated since karaf source tree
> > grew since 2.x without any major changes in directory structure.
> > Till these days it is confusing to me where "enterprise" features come
> > from (in terms of maven POM) and where "framework-static" lives.
> > I do believe that improving tooling and docs will help a lot. I keep
> > getting into troubles with tooling every-so-often.
> >
> >
> > The question where Karaf should or could go.. that's quite difficult to
> > answer. From what I see OSGi marketplace is shrinking year-to-year and
> > recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
> > personal opinion, result of deep organization failure. It simply did not
> > attract enough of people to use, promote and pay for their certification.
> > Beside Eclipse IDE there are still many products which are based on OSGi
> > itself. Yet thanks to above move OSGi and Eclipse are closer than
> > before making all black PR of Eclipse IDE directly transferable to
> > entire OSGi ecosystem.
> >
> > In curium stances we have we need to be rationale about whether we can
> > or can not fight for "microservices" term any more and if any major
> > changes will move us ahead.
> > I doubt if positioning Apache Karaf as an alternative to Spring Boot or
> > other tools in this category will help. I think they fight for slightly
> > different projects than we ever did. Karaf always been middleware
> > platform and not application framework. Making apps on top of it is
> > doable, but probably done mainly by people who used runtime already and
> > didn't want to complicate deployment. We're pretty far from being first
> > choice for application runtime as there are quite many alternatives.
> > Most of applications will not even feel benefit of OSGi.
> > We simply have no marketing power to fight over media buzz sustained by
> > other (especially Spring) communities. Most importantly we have no man
> > power to keep up all satellite projects around. The nature of
> > Spring/Pivotal development is based on number of paid developers and
> > consultants who actively contribute to development of their ecosystem
> > components. Above all they keep doing technical sales promising fast
> > delivery of projects in numbers which we probably never heard of.
> > I know that comparing number of stars on github is worst metric to be
> > used, yet we have 505 starts whereas boot have 51k. *90 times more*.
> >
> > I am afraid we have none of above prerequisities (manpower, marketing,
> > money). All efforts which we depend upon are distributed around multiple
> > top level Apache projects (CXF, Camel, AMQ) and surroundings such as
> OPS4J.
> > We can't get everyone around working on Karaf/OSGi integration, simply
> > because focus of other communities is somewhere else. This means we will
> > have to ship these components and later maintain integration. Shutdown
> > of Apache Geronimo shows that application server era is over and what I
> > hear between sentences is re-birth of OSGi enabled application platform
> > which Apache Geronimo once promised to become.
> > Again, I don't think that switching to microprofile will help us much
> > cause there are existing projects such as Apache TomEE who do that
> > already with help of CDI. What is our advantage over their? OSGi which
> > failed to attract people over past decade? Or smaller footprint in era
> > of GraalVM?
> >
> > Please hear me out. I am not saying that easing adoption of OSGi and
> > Karaf is wrong. I am just saying that its gonna be very difficult to
> > promote it and get other people engaged. So better focus on community we
> > have, serve their needs and simplify their life. If we solve their
> > trouble and do it in reliable way we have chance to survive. Maybe
> > adoptions will continue to grow and will bring more people to help
> > moving forward.
> >
> > Kind regards,
> > Łukasz
> > --
> > Code-House
> > http://code-house.org
> >
> >
> > On 04.11.2020 05:59, Jean-Baptiste Onofre wrote:
> >> Hi guys,
> >>
> >> François and I started to think about Karaf 5 and give an even modern
> flavor to Karaf, including potentially lot of refactoring and changes. We
> think it’s a must have in our patch to the "main modulith runtime".
> >>
> >> Before sharing all details (some have been shared during my talk at
> ApacheCon), we want to move forward on a PoC branch.
> >>
> >> However, we would love to have your inputs and thoughts (think wide ;)).
> >>
> >> So, please, if you have ideas, comments, criticism ;), send me an email
> and I will reply and eventually include your points in the PoC.
> >>
> >> Thanks !
> >> Regards
> >> JB
> >>
>
>
Re: Thinking about Karaf 5 modulith runtime
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Lukasz,
And thanks for your feedback. I think it’s a fair feedback about the current situation.
I think Karaf is one thing and OSGi is another one (for a project perspective).
So, we can drive Karaf roadmap to something different if it makes sense.
Remember, first ServiceMix version was Spring focus before moving to OSGi.
So the other way around can be true.
We can use OSGi internally, and provide some user facing different approaches.
Karaf devx/tool is the first thing to achieve: improve developer experience, simplify test and runtime assembly.
I agree that we don’t have the marketing power of Pivotal (we are "real" open source project after all ;)) and we don’t have a single company providing marketing power.
I think we have two personas:
1. People already using Karaf, and for them, we have to improve and provide a better runtime generally speaking for sure
2. People not using Karaf, using spring boot, cdi, whatever. I doubt we will convince them to switch to Karaf with another programming framework. The purpose is more to try to attract them with a runtime directly supporting their applications but providing adhoc features out of the box for them (the purpose of a runtime).
That’s what I have in mind for now: improve (thanks for devx and other new features), and attract.
Regards
JB
> Le 9 nov. 2020 à 02:42, Łukasz Dywicki <lu...@code-house.org> a écrit :
>
> I am quite late for this discussion and haven't watched your ApacheCon
> talk, hence pardon my points if they're wrong.
>
> Reorganizing code base is highly appreciated since karaf source tree
> grew since 2.x without any major changes in directory structure.
> Till these days it is confusing to me where "enterprise" features come
> from (in terms of maven POM) and where "framework-static" lives.
> I do believe that improving tooling and docs will help a lot. I keep
> getting into troubles with tooling every-so-often.
>
>
> The question where Karaf should or could go.. that's quite difficult to
> answer. From what I see OSGi marketplace is shrinking year-to-year and
> recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
> personal opinion, result of deep organization failure. It simply did not
> attract enough of people to use, promote and pay for their certification.
> Beside Eclipse IDE there are still many products which are based on OSGi
> itself. Yet thanks to above move OSGi and Eclipse are closer than
> before making all black PR of Eclipse IDE directly transferable to
> entire OSGi ecosystem.
>
> In curium stances we have we need to be rationale about whether we can
> or can not fight for "microservices" term any more and if any major
> changes will move us ahead.
> I doubt if positioning Apache Karaf as an alternative to Spring Boot or
> other tools in this category will help. I think they fight for slightly
> different projects than we ever did. Karaf always been middleware
> platform and not application framework. Making apps on top of it is
> doable, but probably done mainly by people who used runtime already and
> didn't want to complicate deployment. We're pretty far from being first
> choice for application runtime as there are quite many alternatives.
> Most of applications will not even feel benefit of OSGi.
> We simply have no marketing power to fight over media buzz sustained by
> other (especially Spring) communities. Most importantly we have no man
> power to keep up all satellite projects around. The nature of
> Spring/Pivotal development is based on number of paid developers and
> consultants who actively contribute to development of their ecosystem
> components. Above all they keep doing technical sales promising fast
> delivery of projects in numbers which we probably never heard of.
> I know that comparing number of stars on github is worst metric to be
> used, yet we have 505 starts whereas boot have 51k. *90 times more*.
>
> I am afraid we have none of above prerequisities (manpower, marketing,
> money). All efforts which we depend upon are distributed around multiple
> top level Apache projects (CXF, Camel, AMQ) and surroundings such as OPS4J.
> We can't get everyone around working on Karaf/OSGi integration, simply
> because focus of other communities is somewhere else. This means we will
> have to ship these components and later maintain integration. Shutdown
> of Apache Geronimo shows that application server era is over and what I
> hear between sentences is re-birth of OSGi enabled application platform
> which Apache Geronimo once promised to become.
> Again, I don't think that switching to microprofile will help us much
> cause there are existing projects such as Apache TomEE who do that
> already with help of CDI. What is our advantage over their? OSGi which
> failed to attract people over past decade? Or smaller footprint in era
> of GraalVM?
>
> Please hear me out. I am not saying that easing adoption of OSGi and
> Karaf is wrong. I am just saying that its gonna be very difficult to
> promote it and get other people engaged. So better focus on community we
> have, serve their needs and simplify their life. If we solve their
> trouble and do it in reliable way we have chance to survive. Maybe
> adoptions will continue to grow and will bring more people to help
> moving forward.
>
> Kind regards,
> Łukasz
> --
> Code-House
> http://code-house.org
>
>
> On 04.11.2020 05:59, Jean-Baptiste Onofre wrote:
>> Hi guys,
>>
>> François and I started to think about Karaf 5 and give an even modern flavor to Karaf, including potentially lot of refactoring and changes. We think it’s a must have in our patch to the "main modulith runtime".
>>
>> Before sharing all details (some have been shared during my talk at ApacheCon), we want to move forward on a PoC branch.
>>
>> However, we would love to have your inputs and thoughts (think wide ;)).
>>
>> So, please, if you have ideas, comments, criticism ;), send me an email and I will reply and eventually include your points in the PoC.
>>
>> Thanks !
>> Regards
>> JB
>>
Re: Thinking about Karaf 5 modulith runtime
Posted by Łukasz Dywicki <lu...@code-house.org>.
I am quite late for this discussion and haven't watched your ApacheCon
talk, hence pardon my points if they're wrong.
Reorganizing code base is highly appreciated since karaf source tree
grew since 2.x without any major changes in directory structure.
Till these days it is confusing to me where "enterprise" features come
from (in terms of maven POM) and where "framework-static" lives.
I do believe that improving tooling and docs will help a lot. I keep
getting into troubles with tooling every-so-often.
The question where Karaf should or could go.. that's quite difficult to
answer. From what I see OSGi marketplace is shrinking year-to-year and
recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
personal opinion, result of deep organization failure. It simply did not
attract enough of people to use, promote and pay for their certification.
Beside Eclipse IDE there are still many products which are based on OSGi
itself. Yet thanks to above move OSGi and Eclipse are closer than
before making all black PR of Eclipse IDE directly transferable to
entire OSGi ecosystem.
In curium stances we have we need to be rationale about whether we can
or can not fight for "microservices" term any more and if any major
changes will move us ahead.
I doubt if positioning Apache Karaf as an alternative to Spring Boot or
other tools in this category will help. I think they fight for slightly
different projects than we ever did. Karaf always been middleware
platform and not application framework. Making apps on top of it is
doable, but probably done mainly by people who used runtime already and
didn't want to complicate deployment. We're pretty far from being first
choice for application runtime as there are quite many alternatives.
Most of applications will not even feel benefit of OSGi.
We simply have no marketing power to fight over media buzz sustained by
other (especially Spring) communities. Most importantly we have no man
power to keep up all satellite projects around. The nature of
Spring/Pivotal development is based on number of paid developers and
consultants who actively contribute to development of their ecosystem
components. Above all they keep doing technical sales promising fast
delivery of projects in numbers which we probably never heard of.
I know that comparing number of stars on github is worst metric to be
used, yet we have 505 starts whereas boot have 51k. *90 times more*.
I am afraid we have none of above prerequisities (manpower, marketing,
money). All efforts which we depend upon are distributed around multiple
top level Apache projects (CXF, Camel, AMQ) and surroundings such as OPS4J.
We can't get everyone around working on Karaf/OSGi integration, simply
because focus of other communities is somewhere else. This means we will
have to ship these components and later maintain integration. Shutdown
of Apache Geronimo shows that application server era is over and what I
hear between sentences is re-birth of OSGi enabled application platform
which Apache Geronimo once promised to become.
Again, I don't think that switching to microprofile will help us much
cause there are existing projects such as Apache TomEE who do that
already with help of CDI. What is our advantage over their? OSGi which
failed to attract people over past decade? Or smaller footprint in era
of GraalVM?
Please hear me out. I am not saying that easing adoption of OSGi and
Karaf is wrong. I am just saying that its gonna be very difficult to
promote it and get other people engaged. So better focus on community we
have, serve their needs and simplify their life. If we solve their
trouble and do it in reliable way we have chance to survive. Maybe
adoptions will continue to grow and will bring more people to help
moving forward.
Kind regards,
Łukasz
--
Code-House
http://code-house.org
On 04.11.2020 05:59, Jean-Baptiste Onofre wrote:
> Hi guys,
>
> François and I started to think about Karaf 5 and give an even modern flavor to Karaf, including potentially lot of refactoring and changes. We think it’s a must have in our patch to the "main modulith runtime".
>
> Before sharing all details (some have been shared during my talk at ApacheCon), we want to move forward on a PoC branch.
>
> However, we would love to have your inputs and thoughts (think wide ;)).
>
> So, please, if you have ideas, comments, criticism ;), send me an email and I will reply and eventually include your points in the PoC.
>
> Thanks !
> Regards
> JB
>