Re: Quarkus Integration https://quarkus.io/

[Francois Papon]

+1 for me!

Karaf static distributions is something that could add many usefull use
cases to Karaf users and help us to promote Karaf not as a pure OSGi
runtime.

regards,

François
fpa...@apache.org

Le 11/10/2019 à 10:29, Jean-Baptiste Onofré a écrit :
> Hi Guillaume,
>
> (cross messages), it's what we did in Winegrower:
>
> https://github.com/jbonofre/winegrower
>
> We have a single classloader but OSGi "flavor": service registry, etc.
>
> You can see on the examples that we are able to use scr, to run the
> shell, to run decanter, etc in winegrower.
>
> I'm ready to donate that with some polishing if users and you think it's
> valuable.
>
> Regards
> JB
>
> On 11/10/2019 10:25, Guillaume Nodet wrote:
>> The other limitation in native-mode to be aware of is the reflection : it's
>> all doable but needs
>> some opt-in so that the reflection informations can be included in the
>> native binary and made available at runtime.
>>
>> Fwiw, the output of Quarkus is a single runnable jar, so everything is
>> flattened.  For embedded dependencies, this may require additional work,
>> but nothing impossible. Problems may come when using the OSGi registry and
>> for class visibility.  The fact that the OSGi framework would work in a
>> single classloader may cause some problems with bundles wrt service and
>> classes visibility, because there would be no hidden classes anymore,
>> everything would be visible to all bundles.  The other problem would
>> definitely be for native mode (reflection and a few other limitations).
>> But a Quarkus JVM mode could definitely be interesting to have for  Karaf
>> static distributions.
>>
>> Even with a few limitations, like forcing the user to align dependencies to
>> avoid multiple versions of the same class which would remove the need for a
>> complex shading mechanism, it could be worth investigating the benefit when
>> booting those karaf static distributions.  I think it could be a big win
>> for Karaf users.
>>
>> Le ven. 11 oct. 2019 à 09:07, Christian Schneider 
>> a écrit :
>>
>>> There is also another issue about embedding dependencies.
>>>
>>> In OSGi it is quite popular to embed dependencies into the bundle with the
>>> original package names.
>>> When used in a flat classloader this makes these embedded packages collide
>>> between bundles. This can be solved though by embedding with a different
>>> unique
>>> classname. I think the shade plugin can do this but I have never tried.
>>>
>>> Christian
>>>
>>> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
>>> gno...@apache.org>:
>>>
 Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
 écrit :

> Just a side note, not necessary about "happens during runtime" ;)
>
> Look on the Karaf static distribution:
>
>
>
>>> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
> you will see that the resolution is "prepared" at build time, the
> runtime resolution is super fast.
>
> Karaf is not necessary "I start empty and I add stuff in it", it can be
> "I prepare all at build for a super fast start".
>
 That's right, but Quarkus goes a lot further than what Karaf does (which
>>> is
 to basically to pre-install the bundles).
 Such Karaf distributions could eventually benefit from Quarkus too, but
 going native Karaf still uses OSGi and dynamic classloading, whereas
 compiling to native imposes the whole world to be know at build time and
 thus prohibits the use of dynamic classloading.
 So I think there would be a path for Karaf to leverage Quarkus but that
 would be very limited in JVM mode, unless Karaf is only used to create a
 Quarkus powered distribution where the OSGi classloading would go away.
>>> In
 a karaf "static" distribution, we could actually think about it, i.e. use
 something like Felix Connect instead of a real Felix / Equinox framework,
 which removes all classloaders afaik.  The only limitation would be to
 choose a way to handle multiple bundle versions, either by rejecting
>>> those
 use cases, or try to shadow them into a different package.


> Regards
> JB
>
> On 11/10/2019 08:17, Patrique Legault wrote:
>> Thank you for your response.
>>
>> That is very interesting to know. I did not know that Quarkus can do
 all
> of
>> that rendering in build time. It makes sense that this is the
>>> opposite
 of
>> OSGi as everythin happens during runtime.
>>
>> Thank you.
>>
>> On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
> gr.grzy...@gmail.com>
>> wrote:
>>
>>> Hello
>>>
>>> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
> descriptions:
>>> *The approach that Quarkus takes is to tailor a runtime that only
> contains
 what your application needs and to boil down most of the dynamics
>>> of
 

Re: Quarkus Integration https://quarkus.io/

[Jean-Baptiste Onofré]

As Romain just reminded me, you can take a look on the "website":

https://jbonofre.github.io/winegrower/

Regards
JB

On 11/10/2019 10:25, Guillaume Nodet wrote:
> The other limitation in native-mode to be aware of is the reflection : it's
> all doable but needs
> some opt-in so that the reflection informations can be included in the
> native binary and made available at runtime.
> 
> Fwiw, the output of Quarkus is a single runnable jar, so everything is
> flattened.  For embedded dependencies, this may require additional work,
> but nothing impossible. Problems may come when using the OSGi registry and
> for class visibility.  The fact that the OSGi framework would work in a
> single classloader may cause some problems with bundles wrt service and
> classes visibility, because there would be no hidden classes anymore,
> everything would be visible to all bundles.  The other problem would
> definitely be for native mode (reflection and a few other limitations).
> But a Quarkus JVM mode could definitely be interesting to have for  Karaf
> static distributions.
> 
> Even with a few limitations, like forcing the user to align dependencies to
> avoid multiple versions of the same class which would remove the need for a
> complex shading mechanism, it could be worth investigating the benefit when
> booting those karaf static distributions.  I think it could be a big win
> for Karaf users.
> 
> Le ven. 11 oct. 2019 à 09:07, Christian Schneider 
> a écrit :
> 
>> There is also another issue about embedding dependencies.
>>
>> In OSGi it is quite popular to embed dependencies into the bundle with the
>> original package names.
>> When used in a flat classloader this makes these embedded packages collide
>> between bundles. This can be solved though by embedding with a different
>> unique
>> classname. I think the shade plugin can do this but I have never tried.
>>
>> Christian
>>
>> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
>> gno...@apache.org>:
>>
>>> Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
>>> écrit :
>>>
 Just a side note, not necessary about "happens during runtime" ;)

 Look on the Karaf static distribution:



>>>
>> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist

 you will see that the resolution is "prepared" at build time, the
 runtime resolution is super fast.

 Karaf is not necessary "I start empty and I add stuff in it", it can be
 "I prepare all at build for a super fast start".

>>>
>>> That's right, but Quarkus goes a lot further than what Karaf does (which
>> is
>>> to basically to pre-install the bundles).
>>> Such Karaf distributions could eventually benefit from Quarkus too, but
>>> going native Karaf still uses OSGi and dynamic classloading, whereas
>>> compiling to native imposes the whole world to be know at build time and
>>> thus prohibits the use of dynamic classloading.
>>> So I think there would be a path for Karaf to leverage Quarkus but that
>>> would be very limited in JVM mode, unless Karaf is only used to create a
>>> Quarkus powered distribution where the OSGi classloading would go away.
>> In
>>> a karaf "static" distribution, we could actually think about it, i.e. use
>>> something like Felix Connect instead of a real Felix / Equinox framework,
>>> which removes all classloaders afaik.  The only limitation would be to
>>> choose a way to handle multiple bundle versions, either by rejecting
>> those
>>> use cases, or try to shadow them into a different package.
>>>
>>>

 Regards
 JB

 On 11/10/2019 08:17, Patrique Legault wrote:
> Thank you for your response.
>
> That is very interesting to know. I did not know that Quarkus can do
>>> all
 of
> that rendering in build time. It makes sense that this is the
>> opposite
>>> of
> OSGi as everythin happens during runtime.
>
> Thank you.
>
> On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
 gr.grzy...@gmail.com>
> wrote:
>
>> Hello
>>
>> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
 descriptions:
>>
>> *The approach that Quarkus takes is to tailor a runtime that only
 contains
>>> what your application needs and to boil down most of the dynamics
>> of
>>> an
>>> enterprise runtime.*
>>>
>>
>> The idea is to get rid of all the parts of the Java runtime aspects
>>> that
>> ... do nothing except preparing your application to run. These are:
>>  – initialization of jaxb context
>>  – configuring Hibernate model
>>  – wiring your CDI beans
>>  – wiring your Spring beans
>>  – generally transforming some metadata (annotations, XMLs,
 configurations,
>> ...) into a live object model that no longer changes (usually
>>> hashmaps)
>>
>> When the model is read, application does it's job. And we all
>> confirm,
 that

Re: Quarkus Integration https://quarkus.io/

[Jean-Baptiste Onofré]

Hi Guillaume,

(cross messages), it's what we did in Winegrower:

https://github.com/jbonofre/winegrower

We have a single classloader but OSGi "flavor": service registry, etc.

You can see on the examples that we are able to use scr, to run the
shell, to run decanter, etc in winegrower.

I'm ready to donate that with some polishing if users and you think it's
valuable.

Regards
JB

On 11/10/2019 10:25, Guillaume Nodet wrote:
> The other limitation in native-mode to be aware of is the reflection : it's
> all doable but needs
> some opt-in so that the reflection informations can be included in the
> native binary and made available at runtime.
> 
> Fwiw, the output of Quarkus is a single runnable jar, so everything is
> flattened.  For embedded dependencies, this may require additional work,
> but nothing impossible. Problems may come when using the OSGi registry and
> for class visibility.  The fact that the OSGi framework would work in a
> single classloader may cause some problems with bundles wrt service and
> classes visibility, because there would be no hidden classes anymore,
> everything would be visible to all bundles.  The other problem would
> definitely be for native mode (reflection and a few other limitations).
> But a Quarkus JVM mode could definitely be interesting to have for  Karaf
> static distributions.
> 
> Even with a few limitations, like forcing the user to align dependencies to
> avoid multiple versions of the same class which would remove the need for a
> complex shading mechanism, it could be worth investigating the benefit when
> booting those karaf static distributions.  I think it could be a big win
> for Karaf users.
> 
> Le ven. 11 oct. 2019 à 09:07, Christian Schneider 
> a écrit :
> 
>> There is also another issue about embedding dependencies.
>>
>> In OSGi it is quite popular to embed dependencies into the bundle with the
>> original package names.
>> When used in a flat classloader this makes these embedded packages collide
>> between bundles. This can be solved though by embedding with a different
>> unique
>> classname. I think the shade plugin can do this but I have never tried.
>>
>> Christian
>>
>> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
>> gno...@apache.org>:
>>
>>> Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
>>> écrit :
>>>
 Just a side note, not necessary about "happens during runtime" ;)

 Look on the Karaf static distribution:



>>>
>> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist

 you will see that the resolution is "prepared" at build time, the
 runtime resolution is super fast.

 Karaf is not necessary "I start empty and I add stuff in it", it can be
 "I prepare all at build for a super fast start".

>>>
>>> That's right, but Quarkus goes a lot further than what Karaf does (which
>> is
>>> to basically to pre-install the bundles).
>>> Such Karaf distributions could eventually benefit from Quarkus too, but
>>> going native Karaf still uses OSGi and dynamic classloading, whereas
>>> compiling to native imposes the whole world to be know at build time and
>>> thus prohibits the use of dynamic classloading.
>>> So I think there would be a path for Karaf to leverage Quarkus but that
>>> would be very limited in JVM mode, unless Karaf is only used to create a
>>> Quarkus powered distribution where the OSGi classloading would go away.
>> In
>>> a karaf "static" distribution, we could actually think about it, i.e. use
>>> something like Felix Connect instead of a real Felix / Equinox framework,
>>> which removes all classloaders afaik.  The only limitation would be to
>>> choose a way to handle multiple bundle versions, either by rejecting
>> those
>>> use cases, or try to shadow them into a different package.
>>>
>>>

 Regards
 JB

 On 11/10/2019 08:17, Patrique Legault wrote:
> Thank you for your response.
>
> That is very interesting to know. I did not know that Quarkus can do
>>> all
 of
> that rendering in build time. It makes sense that this is the
>> opposite
>>> of
> OSGi as everythin happens during runtime.
>
> Thank you.
>
> On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
 gr.grzy...@gmail.com>
> wrote:
>
>> Hello
>>
>> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
 descriptions:
>>
>> *The approach that Quarkus takes is to tailor a runtime that only
 contains
>>> what your application needs and to boil down most of the dynamics
>> of
>>> an
>>> enterprise runtime.*
>>>
>>
>> The idea is to get rid of all the parts of the Java runtime aspects
>>> that
>> ... do nothing except preparing your application to run. These are:
>>  – initialization of jaxb context
>>  – configuring Hibernate model
>>  – wiring your CDI beans
>>  – wiring your Spring beans

Re: Quarkus Integration https://quarkus.io/

[Jean-Baptiste Onofré]

Hi,

yes, it's what we did in winegrower for the examples.

Regards
JB

On 11/10/2019 09:06, Christian Schneider wrote:
> There is also another issue about embedding dependencies.
> 
> In OSGi it is quite popular to embed dependencies into the bundle with the
> original package names.
> When used in a flat classloader this makes these embedded packages collide
> between bundles. This can be solved though by embedding with a different
> unique
> classname. I think the shade plugin can do this but I have never tried.
> 
> Christian
> 
> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
> gno...@apache.org>:
> 
>> Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
>> écrit :
>>
>>> Just a side note, not necessary about "happens during runtime" ;)
>>>
>>> Look on the Karaf static distribution:
>>>
>>>
>>>
>> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
>>>
>>> you will see that the resolution is "prepared" at build time, the
>>> runtime resolution is super fast.
>>>
>>> Karaf is not necessary "I start empty and I add stuff in it", it can be
>>> "I prepare all at build for a super fast start".
>>>
>>
>> That's right, but Quarkus goes a lot further than what Karaf does (which is
>> to basically to pre-install the bundles).
>> Such Karaf distributions could eventually benefit from Quarkus too, but
>> going native Karaf still uses OSGi and dynamic classloading, whereas
>> compiling to native imposes the whole world to be know at build time and
>> thus prohibits the use of dynamic classloading.
>> So I think there would be a path for Karaf to leverage Quarkus but that
>> would be very limited in JVM mode, unless Karaf is only used to create a
>> Quarkus powered distribution where the OSGi classloading would go away.  In
>> a karaf "static" distribution, we could actually think about it, i.e. use
>> something like Felix Connect instead of a real Felix / Equinox framework,
>> which removes all classloaders afaik.  The only limitation would be to
>> choose a way to handle multiple bundle versions, either by rejecting those
>> use cases, or try to shadow them into a different package.
>>
>>
>>>
>>> Regards
>>> JB
>>>
>>> On 11/10/2019 08:17, Patrique Legault wrote:
 Thank you for your response.

 That is very interesting to know. I did not know that Quarkus can do
>> all
>>> of
 that rendering in build time. It makes sense that this is the opposite
>> of
 OSGi as everythin happens during runtime.

 Thank you.

 On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
>>> gr.grzy...@gmail.com>
 wrote:

> Hello
>
> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
>>> descriptions:
>
> *The approach that Quarkus takes is to tailor a runtime that only
>>> contains
>> what your application needs and to boil down most of the dynamics of
>> an
>> enterprise runtime.*
>>
>
> The idea is to get rid of all the parts of the Java runtime aspects
>> that
> ... do nothing except preparing your application to run. These are:
>  – initialization of jaxb context
>  – configuring Hibernate model
>  – wiring your CDI beans
>  – wiring your Spring beans
>  – generally transforming some metadata (annotations, XMLs,
>>> configurations,
> ...) into a live object model that no longer changes (usually
>> hashmaps)
>
> When the model is read, application does it's job. And we all confirm,
>>> that
> if the only goal of Java application is to read file and store it into
> database, starting Hibernate sessionfactory → session and creating
>> Camel
> context to do that is ~95% of entire work. Rest is "read file, store
>> in
> DB".
>
> Quarkus' goal is to move this 95% work to build time. Yes - build
>> time.
> Effectively the goal is to have Java application, that (when starting)
> *already has this model read* - and (in extreme) just mapped in your
> process' virtual memory as set of pages that JVM can already use.
> And it's not only making native JVM images.
>
> This is *directly* opposite to what Karaf (and OSGi in general) is
>> for.
>
> But maybe +Guillaume Nodet  can tell more about it
>>> ;)
>
> regards
> Grzegorz Grzybek
>
> czw., 10 paź 2019 o 23:48 Patrique Legault >>
> napisał(a):
>
>> Yes exactly what I meant.
>>
>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
>> krzys.sobkow...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Do you mean a Karaf feature prviding the Quarkus libraries (like the
>>> Spring or Hibernate feaures)?
>>>
>>> Best regards
>>> Krzysztof
>>>
>>> On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
 Hello Romain,

 Let me just start by saying I probably should have done more
>> research
>> on
 Quarkus before sending off this 

Re: Quarkus Integration https://quarkus.io/

[Guillaume Nodet]

The other limitation in native-mode to be aware of is the reflection : it's
all doable but needs
some opt-in so that the reflection informations can be included in the
native binary and made available at runtime.

Fwiw, the output of Quarkus is a single runnable jar, so everything is
flattened.  For embedded dependencies, this may require additional work,
but nothing impossible. Problems may come when using the OSGi registry and
for class visibility.  The fact that the OSGi framework would work in a
single classloader may cause some problems with bundles wrt service and
classes visibility, because there would be no hidden classes anymore,
everything would be visible to all bundles.  The other problem would
definitely be for native mode (reflection and a few other limitations).
But a Quarkus JVM mode could definitely be interesting to have for  Karaf
static distributions.

Even with a few limitations, like forcing the user to align dependencies to
avoid multiple versions of the same class which would remove the need for a
complex shading mechanism, it could be worth investigating the benefit when
booting those karaf static distributions.  I think it could be a big win
for Karaf users.

Le ven. 11 oct. 2019 à 09:07, Christian Schneider 
a écrit :

> There is also another issue about embedding dependencies.
>
> In OSGi it is quite popular to embed dependencies into the bundle with the
> original package names.
> When used in a flat classloader this makes these embedded packages collide
> between bundles. This can be solved though by embedding with a different
> unique
> classname. I think the shade plugin can do this but I have never tried.
>
> Christian
>
> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
> gno...@apache.org>:
>
> > Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
> > écrit :
> >
> > > Just a side note, not necessary about "happens during runtime" ;)
> > >
> > > Look on the Karaf static distribution:
> > >
> > >
> > >
> >
> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
> > >
> > > you will see that the resolution is "prepared" at build time, the
> > > runtime resolution is super fast.
> > >
> > > Karaf is not necessary "I start empty and I add stuff in it", it can be
> > > "I prepare all at build for a super fast start".
> > >
> >
> > That's right, but Quarkus goes a lot further than what Karaf does (which
> is
> > to basically to pre-install the bundles).
> > Such Karaf distributions could eventually benefit from Quarkus too, but
> > going native Karaf still uses OSGi and dynamic classloading, whereas
> > compiling to native imposes the whole world to be know at build time and
> > thus prohibits the use of dynamic classloading.
> > So I think there would be a path for Karaf to leverage Quarkus but that
> > would be very limited in JVM mode, unless Karaf is only used to create a
> > Quarkus powered distribution where the OSGi classloading would go away.
> In
> > a karaf "static" distribution, we could actually think about it, i.e. use
> > something like Felix Connect instead of a real Felix / Equinox framework,
> > which removes all classloaders afaik.  The only limitation would be to
> > choose a way to handle multiple bundle versions, either by rejecting
> those
> > use cases, or try to shadow them into a different package.
> >
> >
> > >
> > > Regards
> > > JB
> > >
> > > On 11/10/2019 08:17, Patrique Legault wrote:
> > > > Thank you for your response.
> > > >
> > > > That is very interesting to know. I did not know that Quarkus can do
> > all
> > > of
> > > > that rendering in build time. It makes sense that this is the
> opposite
> > of
> > > > OSGi as everythin happens during runtime.
> > > >
> > > > Thank you.
> > > >
> > > > On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
> > > gr.grzy...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hello
> > > >>
> > > >> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
> > > descriptions:
> > > >>
> > > >> *The approach that Quarkus takes is to tailor a runtime that only
> > > contains
> > > >>> what your application needs and to boil down most of the dynamics
> of
> > an
> > > >>> enterprise runtime.*
> > > >>>
> > > >>
> > > >> The idea is to get rid of all the parts of the Java runtime aspects
> > that
> > > >> ... do nothing except preparing your application to run. These are:
> > > >>  – initialization of jaxb context
> > > >>  – configuring Hibernate model
> > > >>  – wiring your CDI beans
> > > >>  – wiring your Spring beans
> > > >>  – generally transforming some metadata (annotations, XMLs,
> > > configurations,
> > > >> ...) into a live object model that no longer changes (usually
> > hashmaps)
> > > >>
> > > >> When the model is read, application does it's job. And we all
> confirm,
> > > that
> > > >> if the only goal of Java application is to read file and store it
> into
> > > >> database, starting Hibernate sessionfactory → session and 

Re: Quarkus Integration https://quarkus.io/

[Jean-Baptiste Onofré]

My point was not to compare Karaf and Quarkus, it was more to mention
the static distribution ;)

I think Winegrower on Quarkus is easy and direct, it could be a Karaf
mode (merging into Karaf). It provides the OSGi programming model with
one flat classloader.

Regards
JB

On 11/10/2019 08:51, Guillaume Nodet wrote:
> Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
> écrit :
> 
>> Just a side note, not necessary about "happens during runtime" ;)
>>
>> Look on the Karaf static distribution:
>>
>>
>> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
>>
>> you will see that the resolution is "prepared" at build time, the
>> runtime resolution is super fast.
>>
>> Karaf is not necessary "I start empty and I add stuff in it", it can be
>> "I prepare all at build for a super fast start".
>>
> 
> That's right, but Quarkus goes a lot further than what Karaf does (which is
> to basically to pre-install the bundles).
> Such Karaf distributions could eventually benefit from Quarkus too, but
> going native Karaf still uses OSGi and dynamic classloading, whereas
> compiling to native imposes the whole world to be know at build time and
> thus prohibits the use of dynamic classloading.
> So I think there would be a path for Karaf to leverage Quarkus but that
> would be very limited in JVM mode, unless Karaf is only used to create a
> Quarkus powered distribution where the OSGi classloading would go away.  In
> a karaf "static" distribution, we could actually think about it, i.e. use
> something like Felix Connect instead of a real Felix / Equinox framework,
> which removes all classloaders afaik.  The only limitation would be to
> choose a way to handle multiple bundle versions, either by rejecting those
> use cases, or try to shadow them into a different package.
> 
> 
>>
>> Regards
>> JB
>>
>> On 11/10/2019 08:17, Patrique Legault wrote:
>>> Thank you for your response.
>>>
>>> That is very interesting to know. I did not know that Quarkus can do all
>> of
>>> that rendering in build time. It makes sense that this is the opposite of
>>> OSGi as everythin happens during runtime.
>>>
>>> Thank you.
>>>
>>> On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
>> gr.grzy...@gmail.com>
>>> wrote:
>>>
 Hello

 I'm not expert on Quarkus (and GraalVM)... Quoting one of the
>> descriptions:

 *The approach that Quarkus takes is to tailor a runtime that only
>> contains
> what your application needs and to boil down most of the dynamics of an
> enterprise runtime.*
>

 The idea is to get rid of all the parts of the Java runtime aspects that
 ... do nothing except preparing your application to run. These are:
  – initialization of jaxb context
  – configuring Hibernate model
  – wiring your CDI beans
  – wiring your Spring beans
  – generally transforming some metadata (annotations, XMLs,
>> configurations,
 ...) into a live object model that no longer changes (usually hashmaps)

 When the model is read, application does it's job. And we all confirm,
>> that
 if the only goal of Java application is to read file and store it into
 database, starting Hibernate sessionfactory → session and creating Camel
 context to do that is ~95% of entire work. Rest is "read file, store in
 DB".

 Quarkus' goal is to move this 95% work to build time. Yes - build time.
 Effectively the goal is to have Java application, that (when starting)
 *already has this model read* - and (in extreme) just mapped in your
 process' virtual memory as set of pages that JVM can already use.
 And it's not only making native JVM images.

 This is *directly* opposite to what Karaf (and OSGi in general) is for.

 But maybe +Guillaume Nodet  can tell more about it
>> ;)

 regards
 Grzegorz Grzybek

 czw., 10 paź 2019 o 23:48 Patrique Legault 
 napisał(a):

> Yes exactly what I meant.
>
> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> krzys.sobkow...@gmail.com> wrote:
>
>> Hi
>>
>> Do you mean a Karaf feature prviding the Quarkus libraries (like the
>> Spring or Hibernate feaures)?
>>
>> Best regards
>> Krzysztof
>>
>> On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
>>> Hello Romain,
>>>
>>> Let me just start by saying I probably should have done more research
> on
>>> Quarkus before sending off this email.
>>>
>>> In my mind when I think of Karaf, I think of a service that allows
>>> developers to simply install a feature into the service and gives
 them
>>> access to a framework that they can then develop against. For
 instance,
>>> installing a version of hibernate, spring, etc...into the Karaf
> service.
>>>
>>> When I saw the Quarkus framework, I thought of a potential
 opportunity
>> for
>>> 

Re: Quarkus Integration https://quarkus.io/

[Christian Schneider]

There is also another issue about embedding dependencies.

In OSGi it is quite popular to embed dependencies into the bundle with the
original package names.
When used in a flat classloader this makes these embedded packages collide
between bundles. This can be solved though by embedding with a different
unique
classname. I think the shade plugin can do this but I have never tried.

Christian

Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
gno...@apache.org>:

> Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
> écrit :
>
> > Just a side note, not necessary about "happens during runtime" ;)
> >
> > Look on the Karaf static distribution:
> >
> >
> >
> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
> >
> > you will see that the resolution is "prepared" at build time, the
> > runtime resolution is super fast.
> >
> > Karaf is not necessary "I start empty and I add stuff in it", it can be
> > "I prepare all at build for a super fast start".
> >
>
> That's right, but Quarkus goes a lot further than what Karaf does (which is
> to basically to pre-install the bundles).
> Such Karaf distributions could eventually benefit from Quarkus too, but
> going native Karaf still uses OSGi and dynamic classloading, whereas
> compiling to native imposes the whole world to be know at build time and
> thus prohibits the use of dynamic classloading.
> So I think there would be a path for Karaf to leverage Quarkus but that
> would be very limited in JVM mode, unless Karaf is only used to create a
> Quarkus powered distribution where the OSGi classloading would go away.  In
> a karaf "static" distribution, we could actually think about it, i.e. use
> something like Felix Connect instead of a real Felix / Equinox framework,
> which removes all classloaders afaik.  The only limitation would be to
> choose a way to handle multiple bundle versions, either by rejecting those
> use cases, or try to shadow them into a different package.
>
>
> >
> > Regards
> > JB
> >
> > On 11/10/2019 08:17, Patrique Legault wrote:
> > > Thank you for your response.
> > >
> > > That is very interesting to know. I did not know that Quarkus can do
> all
> > of
> > > that rendering in build time. It makes sense that this is the opposite
> of
> > > OSGi as everythin happens during runtime.
> > >
> > > Thank you.
> > >
> > > On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
> > gr.grzy...@gmail.com>
> > > wrote:
> > >
> > >> Hello
> > >>
> > >> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
> > descriptions:
> > >>
> > >> *The approach that Quarkus takes is to tailor a runtime that only
> > contains
> > >>> what your application needs and to boil down most of the dynamics of
> an
> > >>> enterprise runtime.*
> > >>>
> > >>
> > >> The idea is to get rid of all the parts of the Java runtime aspects
> that
> > >> ... do nothing except preparing your application to run. These are:
> > >>  – initialization of jaxb context
> > >>  – configuring Hibernate model
> > >>  – wiring your CDI beans
> > >>  – wiring your Spring beans
> > >>  – generally transforming some metadata (annotations, XMLs,
> > configurations,
> > >> ...) into a live object model that no longer changes (usually
> hashmaps)
> > >>
> > >> When the model is read, application does it's job. And we all confirm,
> > that
> > >> if the only goal of Java application is to read file and store it into
> > >> database, starting Hibernate sessionfactory → session and creating
> Camel
> > >> context to do that is ~95% of entire work. Rest is "read file, store
> in
> > >> DB".
> > >>
> > >> Quarkus' goal is to move this 95% work to build time. Yes - build
> time.
> > >> Effectively the goal is to have Java application, that (when starting)
> > >> *already has this model read* - and (in extreme) just mapped in your
> > >> process' virtual memory as set of pages that JVM can already use.
> > >> And it's not only making native JVM images.
> > >>
> > >> This is *directly* opposite to what Karaf (and OSGi in general) is
> for.
> > >>
> > >> But maybe +Guillaume Nodet  can tell more about it
> > ;)
> > >>
> > >> regards
> > >> Grzegorz Grzybek
> > >>
> > >> czw., 10 paź 2019 o 23:48 Patrique Legault  >
> > >> napisał(a):
> > >>
> > >>> Yes exactly what I meant.
> > >>>
> > >>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> > >>> krzys.sobkow...@gmail.com> wrote:
> > >>>
> >  Hi
> > 
> >  Do you mean a Karaf feature prviding the Quarkus libraries (like the
> >  Spring or Hibernate feaures)?
> > 
> >  Best regards
> >  Krzysztof
> > 
> >  On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> > > Hello Romain,
> > >
> > > Let me just start by saying I probably should have done more
> research
> > >>> on
> > > Quarkus before sending off this email.
> > >
> > > In my mind when I think of Karaf, I think of a service that allows
> > > 

Re: Quarkus Integration https://quarkus.io/

[Guillaume Nodet]

Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré  a
écrit :

> Just a side note, not necessary about "happens during runtime" ;)
>
> Look on the Karaf static distribution:
>
>
> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
>
> you will see that the resolution is "prepared" at build time, the
> runtime resolution is super fast.
>
> Karaf is not necessary "I start empty and I add stuff in it", it can be
> "I prepare all at build for a super fast start".
>

That's right, but Quarkus goes a lot further than what Karaf does (which is
to basically to pre-install the bundles).
Such Karaf distributions could eventually benefit from Quarkus too, but
going native Karaf still uses OSGi and dynamic classloading, whereas
compiling to native imposes the whole world to be know at build time and
thus prohibits the use of dynamic classloading.
So I think there would be a path for Karaf to leverage Quarkus but that
would be very limited in JVM mode, unless Karaf is only used to create a
Quarkus powered distribution where the OSGi classloading would go away.  In
a karaf "static" distribution, we could actually think about it, i.e. use
something like Felix Connect instead of a real Felix / Equinox framework,
which removes all classloaders afaik.  The only limitation would be to
choose a way to handle multiple bundle versions, either by rejecting those
use cases, or try to shadow them into a different package.


>
> Regards
> JB
>
> On 11/10/2019 08:17, Patrique Legault wrote:
> > Thank you for your response.
> >
> > That is very interesting to know. I did not know that Quarkus can do all
> of
> > that rendering in build time. It makes sense that this is the opposite of
> > OSGi as everythin happens during runtime.
> >
> > Thank you.
> >
> > On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
> gr.grzy...@gmail.com>
> > wrote:
> >
> >> Hello
> >>
> >> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
> descriptions:
> >>
> >> *The approach that Quarkus takes is to tailor a runtime that only
> contains
> >>> what your application needs and to boil down most of the dynamics of an
> >>> enterprise runtime.*
> >>>
> >>
> >> The idea is to get rid of all the parts of the Java runtime aspects that
> >> ... do nothing except preparing your application to run. These are:
> >>  – initialization of jaxb context
> >>  – configuring Hibernate model
> >>  – wiring your CDI beans
> >>  – wiring your Spring beans
> >>  – generally transforming some metadata (annotations, XMLs,
> configurations,
> >> ...) into a live object model that no longer changes (usually hashmaps)
> >>
> >> When the model is read, application does it's job. And we all confirm,
> that
> >> if the only goal of Java application is to read file and store it into
> >> database, starting Hibernate sessionfactory → session and creating Camel
> >> context to do that is ~95% of entire work. Rest is "read file, store in
> >> DB".
> >>
> >> Quarkus' goal is to move this 95% work to build time. Yes - build time.
> >> Effectively the goal is to have Java application, that (when starting)
> >> *already has this model read* - and (in extreme) just mapped in your
> >> process' virtual memory as set of pages that JVM can already use.
> >> And it's not only making native JVM images.
> >>
> >> This is *directly* opposite to what Karaf (and OSGi in general) is for.
> >>
> >> But maybe +Guillaume Nodet  can tell more about it
> ;)
> >>
> >> regards
> >> Grzegorz Grzybek
> >>
> >> czw., 10 paź 2019 o 23:48 Patrique Legault 
> >> napisał(a):
> >>
> >>> Yes exactly what I meant.
> >>>
> >>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> >>> krzys.sobkow...@gmail.com> wrote:
> >>>
>  Hi
> 
>  Do you mean a Karaf feature prviding the Quarkus libraries (like the
>  Spring or Hibernate feaures)?
> 
>  Best regards
>  Krzysztof
> 
>  On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> > Hello Romain,
> >
> > Let me just start by saying I probably should have done more research
> >>> on
> > Quarkus before sending off this email.
> >
> > In my mind when I think of Karaf, I think of a service that allows
> > developers to simply install a feature into the service and gives
> >> them
> > access to a framework that they can then develop against. For
> >> instance,
> > installing a version of hibernate, spring, etc...into the Karaf
> >>> service.
> >
> > When I saw the Quarkus framework, I thought of a potential
> >> opportunity
>  for
> > Karaf to provide another framework for developers to use. That being
> >>> said
> > if this is something that Karaf already exposes through various other
> > libraries then there is nothing to do.
> >
> > Next time though I will definitely do some more research prior to a
> > proposition.
> >
> > Cheers,
> >
> > On Thu, Sep 26, 2019 at 10:10 AM 

Re: Quarkus Integration https://quarkus.io/

[Guillaume Nodet]

Le ven. 11 oct. 2019 à 06:56, Grzegorz Grzybek  a
écrit :

> Hello
>
> I'm not expert on Quarkus (and GraalVM)... Quoting one of the descriptions:
>
> *The approach that Quarkus takes is to tailor a runtime that only contains
>> what your application needs and to boil down most of the dynamics of an
>> enterprise runtime.*
>>
>
> The idea is to get rid of all the parts of the Java runtime aspects that
> ... do nothing except preparing your application to run. These are:
>  – initialization of jaxb context
>  – configuring Hibernate model
>  – wiring your CDI beans
>  – wiring your Spring beans
>  – generally transforming some metadata (annotations, XMLs,
> configurations, ...) into a live object model that no longer changes
> (usually hashmaps)
>
> When the model is read, application does it's job. And we all confirm,
> that if the only goal of Java application is to read file and store it into
> database, starting Hibernate sessionfactory → session and creating Camel
> context to do that is ~95% of entire work. Rest is "read file, store in DB".
>
> Quarkus' goal is to move this 95% work to build time. Yes - build time.
> Effectively the goal is to have Java application, that (when starting)
> *already has this model read* - and (in extreme) just mapped in your
> process' virtual memory as set of pages that JVM can already use.
> And it's not only making native JVM images.
>
> This is *directly* opposite to what Karaf (and OSGi in general) is for.
>
> But maybe +Guillaume Nodet  can tell more about it ;)
>

Not much to add unless someone has specific questions ...

Guillaume


>
> regards
> Grzegorz Grzybek
>
> czw., 10 paź 2019 o 23:48 Patrique Legault 
> napisał(a):
>
>> Yes exactly what I meant.
>>
>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
>> krzys.sobkow...@gmail.com> wrote:
>>
>> > Hi
>> >
>> > Do you mean a Karaf feature prviding the Quarkus libraries (like the
>> > Spring or Hibernate feaures)?
>> >
>> > Best regards
>> > Krzysztof
>> >
>> > On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
>> > > Hello Romain,
>> > >
>> > > Let me just start by saying I probably should have done more research
>> on
>> > > Quarkus before sending off this email.
>> > >
>> > > In my mind when I think of Karaf, I think of a service that allows
>> > > developers to simply install a feature into the service and gives them
>> > > access to a framework that they can then develop against. For
>> instance,
>> > > installing a version of hibernate, spring, etc...into the Karaf
>> service.
>> > >
>> > > When I saw the Quarkus framework, I thought of a potential opportunity
>> > for
>> > > Karaf to provide another framework for developers to use. That being
>> said
>> > > if this is something that Karaf already exposes through various other
>> > > libraries then there is nothing to do.
>> > >
>> > > Next time though I will definitely do some more research prior to a
>> > > proposition.
>> > >
>> > > Cheers,
>> > >
>> > > On Thu, Sep 26, 2019 at 10:10 AM Jamie G. 
>> > wrote:
>> > >
>> > > > I'm not sure the the ask entails here.
>> > > >
>> > > > Why does it need to be integrated into Karaf? Can Quarkus just
>> publish
>> > > > a feature which Karaf users could install in the usual manner?
>> > > >
>> > > > On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
>> > > >  wrote:
>> > > > > Hi Patrique,
>> > > > >
>> > > > > I have to admit I'm not following, Quarkus is mainly a
>> microprofile
>> > based
>> > > > > server integrated with GraalVM in the IBM/Redhat ecosystem to
>> build
>> > > > > natively a HTTP app (for k8s).
>> > > > > It also supports a JVM mode but then it is like any CDI/JAXRS
>> server.
>> > > > > In this last mode Karaf is already very competitive so I guess it
>> is
>> > not
>> > > > > the target and in the first mode the current challenge of Graal
>> for
>> > Karaf
>> > > > > (OSGi actually) is that it does not support classloading (and
>> > conflicting
>> > > > > API in the same application).
>> > > > >
>> > > > > Concretely my point is that Karaf already supports Tomcat and
>> Jetty
>> > (and
>> > > > > undertow i think) through pax-web and jersey/cxf so it already
>> has a
>> > > > "lean
>> > > > > and efficient Java server". Add all the recent work about
>> > > > containerization
>> > > > > (static resolver, docker mojo etc) and you can couple it with
>> > "container
>> > > > > first framework".
>> > > > >
>> > > > > Finally, still relying on the JVM enable to Karaf to be more
>> > reliable at
>> > > > > runtime that Quarkus in native mode which still has a poor GC
>> > > > > implementation (it will be enhanced but they are not yet there).
>> > > > >
>> > > > > All that to say I'm not sure the outcome you expect of such a
>> task,
>> > can
>> > > > you
>> > > > > refine it a bit maybe?
>> > > > >
>> > > > > Romain Manni-Bucau
>> > > > > @rmannibucau  |  Blog
>> > > > >  | Old Blog
>> > > > > 

Re: Quarkus Integration https://quarkus.io/

[Jean-Baptiste Onofré]

Just a side note, not necessary about "happens during runtime" ;)

Look on the Karaf static distribution:

https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist

you will see that the resolution is "prepared" at build time, the
runtime resolution is super fast.

Karaf is not necessary "I start empty and I add stuff in it", it can be
"I prepare all at build for a super fast start".

Regards
JB

On 11/10/2019 08:17, Patrique Legault wrote:
> Thank you for your response.
> 
> That is very interesting to know. I did not know that Quarkus can do all of
> that rendering in build time. It makes sense that this is the opposite of
> OSGi as everythin happens during runtime.
> 
> Thank you.
> 
> On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, 
> wrote:
> 
>> Hello
>>
>> I'm not expert on Quarkus (and GraalVM)... Quoting one of the descriptions:
>>
>> *The approach that Quarkus takes is to tailor a runtime that only contains
>>> what your application needs and to boil down most of the dynamics of an
>>> enterprise runtime.*
>>>
>>
>> The idea is to get rid of all the parts of the Java runtime aspects that
>> ... do nothing except preparing your application to run. These are:
>>  – initialization of jaxb context
>>  – configuring Hibernate model
>>  – wiring your CDI beans
>>  – wiring your Spring beans
>>  – generally transforming some metadata (annotations, XMLs, configurations,
>> ...) into a live object model that no longer changes (usually hashmaps)
>>
>> When the model is read, application does it's job. And we all confirm, that
>> if the only goal of Java application is to read file and store it into
>> database, starting Hibernate sessionfactory → session and creating Camel
>> context to do that is ~95% of entire work. Rest is "read file, store in
>> DB".
>>
>> Quarkus' goal is to move this 95% work to build time. Yes - build time.
>> Effectively the goal is to have Java application, that (when starting)
>> *already has this model read* - and (in extreme) just mapped in your
>> process' virtual memory as set of pages that JVM can already use.
>> And it's not only making native JVM images.
>>
>> This is *directly* opposite to what Karaf (and OSGi in general) is for.
>>
>> But maybe +Guillaume Nodet  can tell more about it ;)
>>
>> regards
>> Grzegorz Grzybek
>>
>> czw., 10 paź 2019 o 23:48 Patrique Legault 
>> napisał(a):
>>
>>> Yes exactly what I meant.
>>>
>>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
>>> krzys.sobkow...@gmail.com> wrote:
>>>
 Hi

 Do you mean a Karaf feature prviding the Quarkus libraries (like the
 Spring or Hibernate feaures)?

 Best regards
 Krzysztof

 On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> Hello Romain,
>
> Let me just start by saying I probably should have done more research
>>> on
> Quarkus before sending off this email.
>
> In my mind when I think of Karaf, I think of a service that allows
> developers to simply install a feature into the service and gives
>> them
> access to a framework that they can then develop against. For
>> instance,
> installing a version of hibernate, spring, etc...into the Karaf
>>> service.
>
> When I saw the Quarkus framework, I thought of a potential
>> opportunity
 for
> Karaf to provide another framework for developers to use. That being
>>> said
> if this is something that Karaf already exposes through various other
> libraries then there is nothing to do.
>
> Next time though I will definitely do some more research prior to a
> proposition.
>
> Cheers,
>
> On Thu, Sep 26, 2019 at 10:10 AM Jamie G. 
 wrote:
>
>> I'm not sure the the ask entails here.
>>
>> Why does it need to be integrated into Karaf? Can Quarkus just
>>> publish
>> a feature which Karaf users could install in the usual manner?
>>
>> On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
>>  wrote:
>>> Hi Patrique,
>>>
>>> I have to admit I'm not following, Quarkus is mainly a
>> microprofile
 based
>>> server integrated with GraalVM in the IBM/Redhat ecosystem to
>> build
>>> natively a HTTP app (for k8s).
>>> It also supports a JVM mode but then it is like any CDI/JAXRS
>>> server.
>>> In this last mode Karaf is already very competitive so I guess it
>>> is
 not
>>> the target and in the first mode the current challenge of Graal
>> for
 Karaf
>>> (OSGi actually) is that it does not support classloading (and
 conflicting
>>> API in the same application).
>>>
>>> Concretely my point is that Karaf already supports Tomcat and
>> Jetty
 (and
>>> undertow i think) through pax-web and jersey/cxf so it already
>> has
>>> a
>> "lean
>>> and efficient Java server". Add all the recent work about
>> containerization
>>> (static resolver, docker mojo etc) and 

Re: Quarkus Integration https://quarkus.io/

[Patrique Legault]

Thank you for your response.

That is very interesting to know. I did not know that Quarkus can do all of
that rendering in build time. It makes sense that this is the opposite of
OSGi as everythin happens during runtime.

Thank you.

On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, 
wrote:

> Hello
>
> I'm not expert on Quarkus (and GraalVM)... Quoting one of the descriptions:
>
> *The approach that Quarkus takes is to tailor a runtime that only contains
> > what your application needs and to boil down most of the dynamics of an
> > enterprise runtime.*
> >
>
> The idea is to get rid of all the parts of the Java runtime aspects that
> ... do nothing except preparing your application to run. These are:
>  – initialization of jaxb context
>  – configuring Hibernate model
>  – wiring your CDI beans
>  – wiring your Spring beans
>  – generally transforming some metadata (annotations, XMLs, configurations,
> ...) into a live object model that no longer changes (usually hashmaps)
>
> When the model is read, application does it's job. And we all confirm, that
> if the only goal of Java application is to read file and store it into
> database, starting Hibernate sessionfactory → session and creating Camel
> context to do that is ~95% of entire work. Rest is "read file, store in
> DB".
>
> Quarkus' goal is to move this 95% work to build time. Yes - build time.
> Effectively the goal is to have Java application, that (when starting)
> *already has this model read* - and (in extreme) just mapped in your
> process' virtual memory as set of pages that JVM can already use.
> And it's not only making native JVM images.
>
> This is *directly* opposite to what Karaf (and OSGi in general) is for.
>
> But maybe +Guillaume Nodet  can tell more about it ;)
>
> regards
> Grzegorz Grzybek
>
> czw., 10 paź 2019 o 23:48 Patrique Legault 
> napisał(a):
>
> > Yes exactly what I meant.
> >
> > On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> > krzys.sobkow...@gmail.com> wrote:
> >
> > > Hi
> > >
> > > Do you mean a Karaf feature prviding the Quarkus libraries (like the
> > > Spring or Hibernate feaures)?
> > >
> > > Best regards
> > > Krzysztof
> > >
> > > On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> > > > Hello Romain,
> > > >
> > > > Let me just start by saying I probably should have done more research
> > on
> > > > Quarkus before sending off this email.
> > > >
> > > > In my mind when I think of Karaf, I think of a service that allows
> > > > developers to simply install a feature into the service and gives
> them
> > > > access to a framework that they can then develop against. For
> instance,
> > > > installing a version of hibernate, spring, etc...into the Karaf
> > service.
> > > >
> > > > When I saw the Quarkus framework, I thought of a potential
> opportunity
> > > for
> > > > Karaf to provide another framework for developers to use. That being
> > said
> > > > if this is something that Karaf already exposes through various other
> > > > libraries then there is nothing to do.
> > > >
> > > > Next time though I will definitely do some more research prior to a
> > > > proposition.
> > > >
> > > > Cheers,
> > > >
> > > > On Thu, Sep 26, 2019 at 10:10 AM Jamie G. 
> > > wrote:
> > > >
> > > > > I'm not sure the the ask entails here.
> > > > >
> > > > > Why does it need to be integrated into Karaf? Can Quarkus just
> > publish
> > > > > a feature which Karaf users could install in the usual manner?
> > > > >
> > > > > On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
> > > > >  wrote:
> > > > > > Hi Patrique,
> > > > > >
> > > > > > I have to admit I'm not following, Quarkus is mainly a
> microprofile
> > > based
> > > > > > server integrated with GraalVM in the IBM/Redhat ecosystem to
> build
> > > > > > natively a HTTP app (for k8s).
> > > > > > It also supports a JVM mode but then it is like any CDI/JAXRS
> > server.
> > > > > > In this last mode Karaf is already very competitive so I guess it
> > is
> > > not
> > > > > > the target and in the first mode the current challenge of Graal
> for
> > > Karaf
> > > > > > (OSGi actually) is that it does not support classloading (and
> > > conflicting
> > > > > > API in the same application).
> > > > > >
> > > > > > Concretely my point is that Karaf already supports Tomcat and
> Jetty
> > > (and
> > > > > > undertow i think) through pax-web and jersey/cxf so it already
> has
> > a
> > > > > "lean
> > > > > > and efficient Java server". Add all the recent work about
> > > > > containerization
> > > > > > (static resolver, docker mojo etc) and you can couple it with
> > > "container
> > > > > > first framework".
> > > > > >
> > > > > > Finally, still relying on the JVM enable to Karaf to be more
> > > reliable at
> > > > > > runtime that Quarkus in native mode which still has a poor GC
> > > > > > implementation (it will be enhanced but they are not yet there).
> > > > > >
> > > > > > All that to say I'm not sure the outcome you expect of such a
> task,

Re: Quarkus Integration https://quarkus.io/

[Grzegorz Grzybek]

Hello

I'm not expert on Quarkus (and GraalVM)... Quoting one of the descriptions:

*The approach that Quarkus takes is to tailor a runtime that only contains
> what your application needs and to boil down most of the dynamics of an
> enterprise runtime.*
>

The idea is to get rid of all the parts of the Java runtime aspects that
... do nothing except preparing your application to run. These are:
 – initialization of jaxb context
 – configuring Hibernate model
 – wiring your CDI beans
 – wiring your Spring beans
 – generally transforming some metadata (annotations, XMLs, configurations,
...) into a live object model that no longer changes (usually hashmaps)

When the model is read, application does it's job. And we all confirm, that
if the only goal of Java application is to read file and store it into
database, starting Hibernate sessionfactory → session and creating Camel
context to do that is ~95% of entire work. Rest is "read file, store in DB".

Quarkus' goal is to move this 95% work to build time. Yes - build time.
Effectively the goal is to have Java application, that (when starting)
*already has this model read* - and (in extreme) just mapped in your
process' virtual memory as set of pages that JVM can already use.
And it's not only making native JVM images.

This is *directly* opposite to what Karaf (and OSGi in general) is for.

But maybe +Guillaume Nodet  can tell more about it ;)

regards
Grzegorz Grzybek

czw., 10 paź 2019 o 23:48 Patrique Legault 
napisał(a):

> Yes exactly what I meant.
>
> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> krzys.sobkow...@gmail.com> wrote:
>
> > Hi
> >
> > Do you mean a Karaf feature prviding the Quarkus libraries (like the
> > Spring or Hibernate feaures)?
> >
> > Best regards
> > Krzysztof
> >
> > On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> > > Hello Romain,
> > >
> > > Let me just start by saying I probably should have done more research
> on
> > > Quarkus before sending off this email.
> > >
> > > In my mind when I think of Karaf, I think of a service that allows
> > > developers to simply install a feature into the service and gives them
> > > access to a framework that they can then develop against. For instance,
> > > installing a version of hibernate, spring, etc...into the Karaf
> service.
> > >
> > > When I saw the Quarkus framework, I thought of a potential opportunity
> > for
> > > Karaf to provide another framework for developers to use. That being
> said
> > > if this is something that Karaf already exposes through various other
> > > libraries then there is nothing to do.
> > >
> > > Next time though I will definitely do some more research prior to a
> > > proposition.
> > >
> > > Cheers,
> > >
> > > On Thu, Sep 26, 2019 at 10:10 AM Jamie G. 
> > wrote:
> > >
> > > > I'm not sure the the ask entails here.
> > > >
> > > > Why does it need to be integrated into Karaf? Can Quarkus just
> publish
> > > > a feature which Karaf users could install in the usual manner?
> > > >
> > > > On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
> > > >  wrote:
> > > > > Hi Patrique,
> > > > >
> > > > > I have to admit I'm not following, Quarkus is mainly a microprofile
> > based
> > > > > server integrated with GraalVM in the IBM/Redhat ecosystem to build
> > > > > natively a HTTP app (for k8s).
> > > > > It also supports a JVM mode but then it is like any CDI/JAXRS
> server.
> > > > > In this last mode Karaf is already very competitive so I guess it
> is
> > not
> > > > > the target and in the first mode the current challenge of Graal for
> > Karaf
> > > > > (OSGi actually) is that it does not support classloading (and
> > conflicting
> > > > > API in the same application).
> > > > >
> > > > > Concretely my point is that Karaf already supports Tomcat and Jetty
> > (and
> > > > > undertow i think) through pax-web and jersey/cxf so it already has
> a
> > > > "lean
> > > > > and efficient Java server". Add all the recent work about
> > > > containerization
> > > > > (static resolver, docker mojo etc) and you can couple it with
> > "container
> > > > > first framework".
> > > > >
> > > > > Finally, still relying on the JVM enable to Karaf to be more
> > reliable at
> > > > > runtime that Quarkus in native mode which still has a poor GC
> > > > > implementation (it will be enhanced but they are not yet there).
> > > > >
> > > > > All that to say I'm not sure the outcome you expect of such a task,
> > can
> > > > you
> > > > > refine it a bit maybe?
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > > >
> > > > > Le jeu. 26 sept. 2019 à 15:54, 

Re: Quarkus Integration https://quarkus.io/

[Patrique Legault]

Yes exactly what I meant.

On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
krzys.sobkow...@gmail.com> wrote:

> Hi
>
> Do you mean a Karaf feature prviding the Quarkus libraries (like the
> Spring or Hibernate feaures)?
>
> Best regards
> Krzysztof
>
> On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> > Hello Romain,
> >
> > Let me just start by saying I probably should have done more research on
> > Quarkus before sending off this email.
> >
> > In my mind when I think of Karaf, I think of a service that allows
> > developers to simply install a feature into the service and gives them
> > access to a framework that they can then develop against. For instance,
> > installing a version of hibernate, spring, etc...into the Karaf service.
> >
> > When I saw the Quarkus framework, I thought of a potential opportunity
> for
> > Karaf to provide another framework for developers to use. That being said
> > if this is something that Karaf already exposes through various other
> > libraries then there is nothing to do.
> >
> > Next time though I will definitely do some more research prior to a
> > proposition.
> >
> > Cheers,
> >
> > On Thu, Sep 26, 2019 at 10:10 AM Jamie G. 
> wrote:
> >
> > > I'm not sure the the ask entails here.
> > >
> > > Why does it need to be integrated into Karaf? Can Quarkus just publish
> > > a feature which Karaf users could install in the usual manner?
> > >
> > > On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
> > >  wrote:
> > > > Hi Patrique,
> > > >
> > > > I have to admit I'm not following, Quarkus is mainly a microprofile
> based
> > > > server integrated with GraalVM in the IBM/Redhat ecosystem to build
> > > > natively a HTTP app (for k8s).
> > > > It also supports a JVM mode but then it is like any CDI/JAXRS server.
> > > > In this last mode Karaf is already very competitive so I guess it is
> not
> > > > the target and in the first mode the current challenge of Graal for
> Karaf
> > > > (OSGi actually) is that it does not support classloading (and
> conflicting
> > > > API in the same application).
> > > >
> > > > Concretely my point is that Karaf already supports Tomcat and Jetty
> (and
> > > > undertow i think) through pax-web and jersey/cxf so it already has a
> > > "lean
> > > > and efficient Java server". Add all the recent work about
> > > containerization
> > > > (static resolver, docker mojo etc) and you can couple it with
> "container
> > > > first framework".
> > > >
> > > > Finally, still relying on the JVM enable to Karaf to be more
> reliable at
> > > > runtime that Quarkus in native mode which still has a poor GC
> > > > implementation (it will be enhanced but they are not yet there).
> > > >
> > > > All that to say I'm not sure the outcome you expect of such a task,
> can
> > > you
> > > > refine it a bit maybe?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > > Le jeu. 26 sept. 2019 à 15:54, Patrique Legault <
> > > patriquelega...@gmail.com>
> > > > a écrit :
> > > >
> > > > > There is a new framework released by Red Hat called Quarkus, see
> > > > > https://quarkus.io/, it is designed/built for containerization .
> > > > >
> > > > > If integrated within Karaf, we could create a feature that would
> > > install
> > > > > the Quarkus framework within Karaf. This would allow for a lean and
> > > > > efficient Java server with a container first framework embedded
> within
> > > it.
> > > > > Allowing for quick and easy RESTful services development with a low
> > > memory
> > > > > footprint and quick container runtime.
> > > > >
> > > > > Let me know what you think, and if this is worth logging a ticket
> for.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > --
> > > > > *Patrique Legault*
> > > > >
> >
> >
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Apache OpenWhisk PMC Member (https://openwhisk.apache.org/)
> Apache Incubator PMC Member (https://incubator.apache.org/)
> Senior Solution Architect @ Capgemini SSC (
> http://www.capgeminisoftware.pl/)
>
>

Re: Quarkus Integration https://quarkus.io/

[Krzysztof Sobkowiak]

Hi

Do you mean a Karaf feature prviding the Quarkus libraries (like the Spring or 
Hibernate feaures)?

Best regards
Krzysztof

On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> Hello Romain,
> 
> Let me just start by saying I probably should have done more research on
> Quarkus before sending off this email.
> 
> In my mind when I think of Karaf, I think of a service that allows
> developers to simply install a feature into the service and gives them
> access to a framework that they can then develop against. For instance,
> installing a version of hibernate, spring, etc...into the Karaf service.
> 
> When I saw the Quarkus framework, I thought of a potential opportunity for
> Karaf to provide another framework for developers to use. That being said
> if this is something that Karaf already exposes through various other
> libraries then there is nothing to do.
> 
> Next time though I will definitely do some more research prior to a
> proposition.
> 
> Cheers,
> 
> On Thu, Sep 26, 2019 at 10:10 AM Jamie G.  wrote:
> 
> > I'm not sure the the ask entails here.
> > 
> > Why does it need to be integrated into Karaf? Can Quarkus just publish
> > a feature which Karaf users could install in the usual manner?
> > 
> > On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
> >  wrote:
> > > Hi Patrique,
> > > 
> > > I have to admit I'm not following, Quarkus is mainly a microprofile based
> > > server integrated with GraalVM in the IBM/Redhat ecosystem to build
> > > natively a HTTP app (for k8s).
> > > It also supports a JVM mode but then it is like any CDI/JAXRS server.
> > > In this last mode Karaf is already very competitive so I guess it is not
> > > the target and in the first mode the current challenge of Graal for Karaf
> > > (OSGi actually) is that it does not support classloading (and conflicting
> > > API in the same application).
> > > 
> > > Concretely my point is that Karaf already supports Tomcat and Jetty (and
> > > undertow i think) through pax-web and jersey/cxf so it already has a
> > "lean
> > > and efficient Java server". Add all the recent work about
> > containerization
> > > (static resolver, docker mojo etc) and you can couple it with "container
> > > first framework".
> > > 
> > > Finally, still relying on the JVM enable to Karaf to be more reliable at
> > > runtime that Quarkus in native mode which still has a poor GC
> > > implementation (it will be enhanced but they are not yet there).
> > > 
> > > All that to say I'm not sure the outcome you expect of such a task, can
> > you
> > > refine it a bit maybe?
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > 
> > > 
> > > Le jeu. 26 sept. 2019 à 15:54, Patrique Legault <
> > patriquelega...@gmail.com>
> > > a écrit :
> > > 
> > > > There is a new framework released by Red Hat called Quarkus, see
> > > > https://quarkus.io/, it is designed/built for containerization .
> > > > 
> > > > If integrated within Karaf, we could create a feature that would
> > install
> > > > the Quarkus framework within Karaf. This would allow for a lean and
> > > > efficient Java server with a container first framework embedded within
> > it.
> > > > Allowing for quick and easy RESTful services development with a low
> > memory
> > > > footprint and quick container runtime.
> > > > 
> > > > Let me know what you think, and if this is worth logging a ticket for.
> > > > 
> > > > Cheers,
> > > > 
> > > > --
> > > > *Patrique Legault*
> > > > 
> 
> 
-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Apache OpenWhisk PMC Member (https://openwhisk.apache.org/)
Apache Incubator PMC Member (https://incubator.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: Quarkus Integration https://quarkus.io/

[Patrique Legault]

Hello Romain,

Let me just start by saying I probably should have done more research on
Quarkus before sending off this email.

In my mind when I think of Karaf, I think of a service that allows
developers to simply install a feature into the service and gives them
access to a framework that they can then develop against. For instance,
installing a version of hibernate, spring, etc...into the Karaf service.

When I saw the Quarkus framework, I thought of a potential opportunity for
Karaf to provide another framework for developers to use. That being said
if this is something that Karaf already exposes through various other
libraries then there is nothing to do.

Next time though I will definitely do some more research prior to a
proposition.

Cheers,

On Thu, Sep 26, 2019 at 10:10 AM Jamie G.  wrote:

> I'm not sure the the ask entails here.
>
> Why does it need to be integrated into Karaf? Can Quarkus just publish
> a feature which Karaf users could install in the usual manner?
>
> On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
>  wrote:
> >
> > Hi Patrique,
> >
> > I have to admit I'm not following, Quarkus is mainly a microprofile based
> > server integrated with GraalVM in the IBM/Redhat ecosystem to build
> > natively a HTTP app (for k8s).
> > It also supports a JVM mode but then it is like any CDI/JAXRS server.
> > In this last mode Karaf is already very competitive so I guess it is not
> > the target and in the first mode the current challenge of Graal for Karaf
> > (OSGi actually) is that it does not support classloading (and conflicting
> > API in the same application).
> >
> > Concretely my point is that Karaf already supports Tomcat and Jetty (and
> > undertow i think) through pax-web and jersey/cxf so it already has a
> "lean
> > and efficient Java server". Add all the recent work about
> containerization
> > (static resolver, docker mojo etc) and you can couple it with "container
> > first framework".
> >
> > Finally, still relying on the JVM enable to Karaf to be more reliable at
> > runtime that Quarkus in native mode which still has a poor GC
> > implementation (it will be enhanced but they are not yet there).
> >
> > All that to say I'm not sure the outcome you expect of such a task, can
> you
> > refine it a bit maybe?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 26 sept. 2019 à 15:54, Patrique Legault <
> patriquelega...@gmail.com>
> > a écrit :
> >
> > > There is a new framework released by Red Hat called Quarkus, see
> > > https://quarkus.io/, it is designed/built for containerization .
> > >
> > > If integrated within Karaf, we could create a feature that would
> install
> > > the Quarkus framework within Karaf. This would allow for a lean and
> > > efficient Java server with a container first framework embedded within
> it.
> > > Allowing for quick and easy RESTful services development with a low
> memory
> > > footprint and quick container runtime.
> > >
> > > Let me know what you think, and if this is worth logging a ticket for.
> > >
> > > Cheers,
> > >
> > > --
> > > *Patrique Legault*
> > >
>


-- 
*Patrique Legault*

Re: Quarkus Integration https://quarkus.io/

[Jamie G.]

I'm not sure the the ask entails here.

Why does it need to be integrated into Karaf? Can Quarkus just publish
a feature which Karaf users could install in the usual manner?

On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
 wrote:
>
> Hi Patrique,
>
> I have to admit I'm not following, Quarkus is mainly a microprofile based
> server integrated with GraalVM in the IBM/Redhat ecosystem to build
> natively a HTTP app (for k8s).
> It also supports a JVM mode but then it is like any CDI/JAXRS server.
> In this last mode Karaf is already very competitive so I guess it is not
> the target and in the first mode the current challenge of Graal for Karaf
> (OSGi actually) is that it does not support classloading (and conflicting
> API in the same application).
>
> Concretely my point is that Karaf already supports Tomcat and Jetty (and
> undertow i think) through pax-web and jersey/cxf so it already has a "lean
> and efficient Java server". Add all the recent work about containerization
> (static resolver, docker mojo etc) and you can couple it with "container
> first framework".
>
> Finally, still relying on the JVM enable to Karaf to be more reliable at
> runtime that Quarkus in native mode which still has a poor GC
> implementation (it will be enhanced but they are not yet there).
>
> All that to say I'm not sure the outcome you expect of such a task, can you
> refine it a bit maybe?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le jeu. 26 sept. 2019 à 15:54, Patrique Legault 
> a écrit :
>
> > There is a new framework released by Red Hat called Quarkus, see
> > https://quarkus.io/, it is designed/built for containerization .
> >
> > If integrated within Karaf, we could create a feature that would install
> > the Quarkus framework within Karaf. This would allow for a lean and
> > efficient Java server with a container first framework embedded within it.
> > Allowing for quick and easy RESTful services development with a low memory
> > footprint and quick container runtime.
> >
> > Let me know what you think, and if this is worth logging a ticket for.
> >
> > Cheers,
> >
> > --
> > *Patrique Legault*
> >

Re: Quarkus Integration https://quarkus.io/

[Romain Manni-Bucau]

Hi Patrique,

I have to admit I'm not following, Quarkus is mainly a microprofile based
server integrated with GraalVM in the IBM/Redhat ecosystem to build
natively a HTTP app (for k8s).
It also supports a JVM mode but then it is like any CDI/JAXRS server.
In this last mode Karaf is already very competitive so I guess it is not
the target and in the first mode the current challenge of Graal for Karaf
(OSGi actually) is that it does not support classloading (and conflicting
API in the same application).

Concretely my point is that Karaf already supports Tomcat and Jetty (and
undertow i think) through pax-web and jersey/cxf so it already has a "lean
and efficient Java server". Add all the recent work about containerization
(static resolver, docker mojo etc) and you can couple it with "container
first framework".

Finally, still relying on the JVM enable to Karaf to be more reliable at
runtime that Quarkus in native mode which still has a poor GC
implementation (it will be enhanced but they are not yet there).

All that to say I'm not sure the outcome you expect of such a task, can you
refine it a bit maybe?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 26 sept. 2019 à 15:54, Patrique Legault 
a écrit :

> There is a new framework released by Red Hat called Quarkus, see
> https://quarkus.io/, it is designed/built for containerization .
>
> If integrated within Karaf, we could create a feature that would install
> the Quarkus framework within Karaf. This would allow for a lean and
> efficient Java server with a container first framework embedded within it.
> Allowing for quick and easy RESTful services development with a low memory
> footprint and quick container runtime.
>
> Let me know what you think, and if this is worth logging a ticket for.
>
> Cheers,
>
> --
> *Patrique Legault*
>