Hi Greg Thanks for the update. I'm in vacation this week. I will ping you as soon as I will be back.
Regards JB On Oct 31, 2017, 12:52, at 12:52, Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: >@JBO sure > >I'm on IRC Mon-Fri ;) > >I'm not going to force my idea. The reasoning behind this is my >experience >when trying to align feature/bundle versions from CXF, Camel, ActiveMQ, >hawtio, fabric8, switchyard, PAX (Web, CDI, JDBC, JMS), JClouds, >Hibernate.... In most cases, "<bundle depdendency="true">" helps, but >it's >not always a case. Having 6 different scala-library bundles or shipping >8 >different guava bundles in a distro wasn't nice... > >This is not going to be "user friendly" tool, it's rather aimed for >distro >creators, where you want to control more aspects of versions without >having >to fork. > >best regards >Grzegorz Grzybek > > >2017-10-31 12:37 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > >> 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 ><gr.grzy...@gmail.com> >> 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 >>
