Hello 2017-10-31 13:49 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> Hi Greg > > Thanks for the update. I'm in vacation this week. I will ping you as soon > as I will be back. > Thanks. If you have any quick comments, please share ;) regards Grzegorz > 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 > >> >
