Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Grzegorz Grzybek]

Hello

2017-10-31 13:49 GMT+01:00 Jean-Baptiste Onofré :

> 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 
> 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, "" 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é :
> >
> >> 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
> >
> >> 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
> >>
>

Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Jean-Baptiste Onofré]

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  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, "" 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é :
>
>> 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
>
>> 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
>>

Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Grzegorz Grzybek]

@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, "" 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é :

> 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 
> 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
>

Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Jean-Baptiste Onofré]

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  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

Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Francois Papon]

Hello,

For me it's good :)

+1


Le 31/10/2017 à 13:21, Grzegorz Grzybek a écrit :
> Hello
>
> Continuing the thread, here's draft XML configuration file for feature
> overriding/altering/blacklisting. This file could be generated by
> karaf-maven-plugin and could be used in addition to/instead of
> etc/overrides.properties and/or etc/blacklisted.properties:
>
> 
>
> http://karaf.apache.org/xmlns/features-processing/v1.0.0;>
>
> 
> 
>
> mvn:org.hibernate/hibernate-validator-osgi-karaf-features/5.*/xml/features
> 
> 
>
> 
> 
> *jetty*
> 
> 
>
> 
> 
> mvn:commons-logging/*
> 
> 
>
> 
> 
> 
>  url="mvn:org.ops4j.pax.cdi/pax-cdi-features/*/xml/features"
> dependency="true" />
> 
> 
> 
> 
>  dependency="true" />
> 
>
> 
> 
> 
> replacement="mvn:org.apache.geronimo.specs/geronimo-servlet_3.0_spec/1.0" />
> 
> 
>
> 
> 
>  version="6.0.7">
> pax-jsf-support
>  dependency="true">mvn:org.ops4j.pax.web/pax-web-resources-extender/6.0.7
>
> mvn:org.ops4j.pax.web/pax-web-resources-jsf/6.0.7
> 
> 
> 
>
> 
>
> What do you think?
>
> regards
> Grzegorz Grzybek
>
> 2017-10-30 15:08 GMT+01:00 Grzegorz Grzybek :
>
>> 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
>>

Re: Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Grzegorz Grzybek]

Hello

Continuing the thread, here's draft XML configuration file for feature
overriding/altering/blacklisting. This file could be generated by
karaf-maven-plugin and could be used in addition to/instead of
etc/overrides.properties and/or etc/blacklisted.properties:



http://karaf.apache.org/xmlns/features-processing/v1.0.0;>




mvn:org.hibernate/hibernate-validator-osgi-karaf-features/5.*/xml/features





*jetty*





mvn:commons-logging/*























pax-jsf-support
mvn:org.ops4j.pax.web/pax-web-resources-extender/6.0.7

mvn:org.ops4j.pax.web/pax-web-resources-jsf/6.0.7






What do you think?

regards
Grzegorz Grzybek

2017-10-30 15:08 GMT+01:00 Grzegorz Grzybek :

> 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
>

Integrating "overrides" and "blacklisting" for repositories, features and bundles

[Grzegorz Grzybek]

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