Hi >From a quick glance, it sounds good to me. However I would like to take a >deeper look and discuss with you about that.
Regards JB On Oct 30, 2017, 15:09, at 15:09, Grzegorz Grzybek <[email protected]> wrote: >Hello > >Continuing my investigation of Processor mechanism for feature >definitions >(a.k.a. "better overrides")[1], I want to give you insight to what I >plan >to change in Karaf's FeatureService. > >Currently we have two separate mechanisms: > >"blacklisting": > - may remove bundles from feature at features XML load time > - may remove features from repository at features XML load time >- may skip adding/analyzing features XML at karaf-maven-plugin:assembly >invocation time > - doesn't prevent given features XML to be added later >- clears runtime information about blacklisted features/bundles - we >can't >query for blacklisted features or see (in `feature:list`) which >features >were blacklisted > >"overrides": >- may replace G:A:V of some bundle with another G:A:V2 when downloading >bundles of a feature > - doesn't allow to change G:A:V into different G2:A2:V2 (e.g., >"mvn:org.eclipse.jetty.orbit/javax.servlet/3.0.0.v201112011016" → >"mvn:org.apache.geronimo.specs/geronimo-servlet_3.0_spec/1.0") > - doesn't allow to change "dependency" flag on given bundle > - doesn't allow to add bundles to a feature (assuming we "know better" >than original feature's author - but it's a problem more often than >we'd >want) > >What I'm working on (till you tell me we don't need it), is better >separation of concerns. I assume that feature XML files are loaded in >one >place (JAXB) and then may be further processed (which involves >blacklisting, overriding and altering of entire features) before >they're >actually used by FeaturesService. > >Currently org.apache.karaf.features.internal.service.RepositoryCache >class >holds JAXB model and uses >org.apache.karaf.features.internal.service.Blacklist class to alter (to >some degree) it. >I want to integrate "Blacklist" class into more generic >org.apache.karaf.features.internal.service.FeaturesProcessor interface. > >Repository, Feature and BundleInfo classes will have "isBlacklisted()" >method for diagnostic purposes. Blacklisted items are not simply >removed, >but can't be used to alter runtime (State). > >I want to be as much consistent between FeaturesService (dynamic >aspect) >and karaf-maven-plugin:assembly (static aspect) as possible. Maven >goal's >configuration will be used to generate special (new?) file in etc/ of >the >distro and then used at runtime. > >As the area I'm playing with is very fragile, it's slower (than I want) >process. I'll continue my work, but I welcome any comments if I attempt >something silly. > >regards >Grzegorz Grzybek >=== >[1]: https://issues.apache.org/jira/browse/KARAF-5376
