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