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 <ch...@die-schneider.net>
> 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é <j...@nanthrax.net> 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 <gno...@apache.org> can tell more about
>> it
>>>> ;)
>>>>>>
>>>>>> regards
>>>>>> Grzegorz Grzybek
>>>>>>
>>>>>> czw., 10 paź 2019 o 23:48 Patrique Legault <
>> patriquelega...@gmail.com
>>>>
>>>>>> 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. <
>>> jamie.goody...@gmail.com>
>>>>>>>> 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
>>>>>>>>>> <rmannibu...@gmail.com> 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 <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 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/)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbono...@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Computer Scientist
>> http://www.adobe.com
>>
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to