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
