I agree with Achim. The problem I see with a simple resolver is especially that it will come to a different result than the current resolver. So the features shipped with karaf might behave differently with a simple resolver. So maybe this can work if people do all feature on their own but this is not how people use karaf.
Christian Am Di., 5. Mai 2020 um 11:50 Uhr schrieb Achim Nierbeck <bcanh...@googlemail.com.invalid>: > +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> > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
