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é <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 >> > > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
