+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 >> >> >>
