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