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>
