:) 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 > > > > > >
