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 <[email protected] >: > 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 <[email protected]> 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 <[email protected] > .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 < > > > [email protected]>: > > > > > >> +1 for all > > >> > > >> regards, > > >> > > >> François > > >> [email protected] > > >> > > >> 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 <[email protected]> > > >> 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
