That’s the idea: the resolution should be performed at build time, and the same resolution should happen at runtime. It’s not always the case.
Anyway, as we don’t have a consensus, I’m moving back on the resolver. Instead I’m working on: 1. Improve log message for runtime resolution 2. Improve build tool (part of devx) for build time resolution Regards JB > Le 6 mai 2020 à 09:05, Guillaume Nodet <gno...@apache.org> a écrit : > > 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
