Don't want to hijack this thread which is very interesting in terms of user features IMHO but it is important to mention that quarkus is "just" a wrapper around graalvm as Geronimo Arthur is (even if Quarkus has a way more complete ecosystem) and that we already have OSGi graalvm integrations so I suspect karaf-quarkus is kind of the same as putting karaf in a war in a tomcat, doable but... That said making Karaf immutable at build time (and the underlying osgi system with its "state" already provisionned) is a great and important feature for K8s (not microservices or docker which are other things IMHO ;)).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 6 mai 2020 à 10:47, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit : > :) > > I was thinking about karaf-quarkus extension. But I'm not experienced > enough (with Quarkus) to provide any solution (for now). > > regards > Grzegorz Grzybek > > śr., 6 maj 2020 o 10:45 Romain Manni-Bucau <rmannibu...@gmail.com> > napisał(a): > > > s/quarkus/karaf/ ;) > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mer. 6 mai 2020 à 10:44, Grzegorz Grzybek <gr.grzy...@gmail.com> a > > écrit : > > > > > Hello > > > > > > BTW. Wiring/resolving reqs/caps at build time is perfect use-case for > > > Quarkus ;) > > > > > > regards > > > Grzegorz Grzybek > > > > > > śr., 6 maj 2020 o 10:39 Christian Schneider <ch...@die-schneider.net> > > > napisał(a): > > > > > > > I agree that for microservices the resolver should be run at build > time > > > and > > > > use static for the runtime. > > > > That also avoids all the refresh issues for optional packages. > > > > > > > > Christian > > > > > > > > Am Mi., 6. Mai 2020 um 09:05 Uhr schrieb Guillaume Nodet < > > > > gno...@apache.org > > > > >: > > > > > > > > > The resolver pain can be absorbed at build time when building the > > > > assembly > > > > > if the target is a micro-service. > > > > > The maven plugin can easily be used to build a customized > > distribution, > > > > > totally removing the need for the resolver at runtime. > > > > > You were thinking to fill a gap between the dynamic/standard and > the > > > > static > > > > > distributions ? I'm not yet convinced there's a real gap between > > those > > > 2 > > > > > scenarii. > > > > > > > > > > Guillaume > > > > > > > > > > Le mer. 6 mai 2020 à 06:59, Jean-Baptiste Onofre <j...@nanthrax.net> > a > > > > > écrit : > > > > > > > > > > > The problem is that regular resolver makes sense for > > > "dynamic/standard" > > > > > > distribution, but very painful for "cloud/light/straight" > runtime. > > > > > > > > > > > > The proposal is to have a lighter version of the resolver to be > > > faster > > > > > and > > > > > > predictable. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > > Le 5 mai 2020 à 11:50, Achim Nierbeck <bcanh...@googlemail.com > > > > > .INVALID> > > > > > > a écrit : > > > > > > > > > > > > > > +1 for most. > > > > > > > only objection to the "Simple" Resolver, therefore -1 on that. > > > > > > > I fear we do more harm then improvement. > > > > > > > As Grzegorz already said, it's the way it is, not because we > love > > > > > complex > > > > > > > stuff, but because bundle resolving is complex. > > > > > > > Especially due to the new req/cap inside bundles. > > > > > > > Actually to work around some of the "crappy" req/cap with > > bundles, > > > > with > > > > > > > features did help in the past. > > > > > > > > > > > > > > regards, Achim > > > > > > > > > > > > > > > > > > > > > Am Mo., 4. Mai 2020 um 09:44 Uhr schrieb Francois Papon < > > > > > > > francois.pa...@openobject.fr>: > > > > > > > > > > > > > >> +1 for all > > > > > > >> > > > > > > >> regards, > > > > > > >> > > > > > > >> François > > > > > > >> fpa...@apache.org > > > > > > >> > > > > > > >> Le 04/05/2020 à 09:26, Grzegorz Grzybek a écrit : > > > > > > >>> Hello > > > > > > >>> > > > > > > >>> ad1) About JAXB. Currently, > > > > > > >>> `org.apache.karaf.features.internal.model.processing` package > > > > > contains > > > > > > >> not > > > > > > >>> that complex model for "Feature override and blacklisting", > > which > > > > > reads > > > > > > >>> etc/org.apache.karaf.features.xml file to _alter_ features > > model > > > > > using > > > > > > >>> > `org.apache.karaf.features.internal.service.FeaturesProcessor`. > > > > > > >>> Nothing that can't be done without JAXB. But I'd have to > > rewrite > > > > some > > > > > > >> code > > > > > > >>> to use StAX/SAX instead. > > > > > > >>> > > > > > > >>> ad2) as long as the _model_ read from JSON feature files is > > still > > > > > > rooted > > > > > > >> at > > > > > > >>> org.apache.karaf.features.internal.model.Features class, it's > > > fine > > > > > wrt > > > > > > >>> _feature processing_ ;) > > > > > > >>> > > > > > > >>> ad3) +1 for simpler resolver. But I remember it's complex not > > for > > > > the > > > > > > >> sake > > > > > > >>> of complexity, but due to complexity of bundle model and > > > reqs/caps > > > > > > >> model. I > > > > > > >>> have a _strange case_ in > > > > > > >>> > https://github.com/apache/karaf/commits/ggrzybek-conditionals, > > > > where > > > > > > >>> resolution depends on whether (or not) a feature is in > > > > > > >>> <conditional>/<condition>. > > > > > > >>> > > > > > > >>> ad4) +1 > > > > > > >>> > > > > > > >>> ad5) +2 > > > > > > >>> > > > > > > >>> regards > > > > > > >>> Grzegorz Grzybek > > > > > > >>> > > > > > > >>> pon., 4 maj 2020 o 07:30 Jean-Baptiste Onofre < > j...@nanthrax.net > > > > > > > > > >> napisał(a): > > > > > > >>> > > > > > > >>>> Hi guys, > > > > > > >>>> > > > > > > >>>> I’m working on several improvements this week where I would > > need > > > > > your > > > > > > >>>> review and thoughts. > > > > > > >>>> > > > > > > >>>> 1. JAXB remove > > > > > > >>>> We have a JAXB dependency in Karaf core just for the > features > > > > > service. > > > > > > >> As > > > > > > >>>> the features model is "static" (we don’t change features > model > > > at > > > > > > >> runtime), > > > > > > >>>> I would like to remove the JAXB dependency and generate the > > > parser > > > > > at > > > > > > >> build > > > > > > >>>> time with SXC for instance. I will add a build profile to > > > generate > > > > > the > > > > > > >>>> parse when the model change (it doesn’t happen very often to > > be > > > > > > honest). > > > > > > >>>> The purpose is to provide a even lighter Karaf runtime. > About > > > > that, > > > > > I > > > > > > >>>> would like also to promote a bit the minimal distribution > and > > do > > > > it > > > > > > even > > > > > > >>>> lighter. I propose to push minimal as official docker image, > > > > > allowing > > > > > > >>>> people to start from minimal to create their own docker > image > > > (we > > > > > will > > > > > > >>>> provide improved tools about that). > > > > > > >>>> > > > > > > >>>> 2. Features JSON > > > > > > >>>> As an alternative to features XML repo, I’ve working on > > features > > > > > JSON > > > > > > >>>> repo. It’s similar in term of content, but you will now have > > the > > > > > > choice > > > > > > >>>> between XML and JSON. > > > > > > >>>> > > > > > > >>>> 3. Simple resolver > > > > > > >>>> Several users complained about the features resolver: it > might > > > be > > > > > seen > > > > > > >> as > > > > > > >>>> complex (you have to understand req/caps, etc), it’s not > > always > > > > > > >> predictable > > > > > > >>>> (due to refresh with optional import, etc). I would like to > > > > propose > > > > > an > > > > > > >>>> alternative: the simple resolver. It’s pretty simple: it > just > > > > takes > > > > > > what > > > > > > >>>> you have in features definition. It’s an optional resolver, > > > > meaning > > > > > > that > > > > > > >>>> the default will be still the regular resolver. The simple > > > > resolver > > > > > > can > > > > > > >> be > > > > > > >>>> enabled in etc/org.apache.karaf.features.cfg. > > > > > > >>>> > > > > > > >>>> 4. Spec features and cleanup > > > > > > >>>> As already discussed, I would like to remove the > lib/jdk9plus > > > > folder > > > > > > and > > > > > > >>>> all spec packages from etc/jre.properties to use spec > features > > > > > > instead. > > > > > > >>>> That will give us more control in the specs version and > > support > > > of > > > > > > JDK. > > > > > > >>>> > > > > > > >>>> 5. ConfigAdmin persistence repository overwrite with env var > > > > > > >>>> It will be possible now to overwrite configuration with env > > var. > > > > For > > > > > > >>>> instance, if you have a property foo in my.config pid, you > > will > > > be > > > > > > able > > > > > > >> to > > > > > > >>>> overwrite this property with -Dmy.config:foo=bar at > bootstrap. > > > > > > >>>> > > > > > > >>>> If you agree, I would like to include those improvements in > > > coming > > > > > > >> release > > > > > > >>>> (4.2.9 and 4.3.0.RC2). > > > > > > >>>> > > > > > > >>>> Regards > > > > > > >>>> JB > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Apache Member > > > > > > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > > > > > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > > > > > Committer > > > > > > & > > > > > > > Project Lead > > > > > > > blog <http://notizblog.nierbeck.de/> > > > > > > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > > > > > > > > > > > > > > > > > > > > > -- > > > > > ------------------------ > > > > > Guillaume Nodet > > > > > > > > > > > > > > > > > -- > > > > -- > > > > Christian Schneider > > > > http://www.liquid-reality.de > > > > > > > > Computer Scientist > > > > http://www.adobe.com > > > > > > > > > >
