karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles
Date Tue, 31 Oct 2017 12:57:04 GMT
Hello

2017-10-31 13:49 GMT+01:00 Jean-Baptiste Onofré <jb@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.grzybek@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é <jb@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.grzybek@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
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message