Long time user, non-committer chiming in. 1. +1. I’ve got some dev cycles to pitch in on this.
2. Suggest: Add a jsonType field to fully qualify the version of the feature file in JSON, since last I checked JSON doesn’t have a standardized namespace mechanism (ie. jsonType=“org.apache.karaf.features.v130.Features”). I’ve got some dev cycles to pitch in on this. 3. I don’t see an issue w/ having a non-default simple resolver as a configurable option 4. +1 5. Override with an env or sys property, or both? I think with the advent of containers the preferred resolution order has been flipped from cfg -> sys -> env vs env -> sys -> cfg previously. Perhaps an option to set a resolution order would be a way to capture all scenarios? Thanks, -Matt > On May 4, 2020, at 12:31 AM, Jean-Baptiste Onofre <j...@nanthrax.net> wrote: > > 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 > >
