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 >
