Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
MIME-Version: 1.0
In-Reply-To: <CAAdXmhpCV-qL2pPOKeo--3avfbDtx2Ray3KhVjdJb=QNTMZptg@mail.gmail.com>
References: <CAAdXmhpCV-qL2pPOKeo--3avfbDtx2Ray3KhVjdJb=QNTMZptg@mail.gmail.com>
From: Grzegorz Grzybek <gr.grzybek@gmail.com>
Date: Tue, 31 Oct 2017 10:21:58 +0100
Message-ID: <CAAdXmhqdKmvUbXXsXHz5DNTnGOfy_T4noqXDFW-=7O9YaoOASQ@mail.gmail.com>
Subject: Re: Integrating "overrides" and "blacklisting" for repositories,
 features and bundles
To: dev@karaf.apache.org
Content-Type: multipart/alternative; boundary="94eb2c0749bea713ba055cd44ade"
archived-at: Tue, 31 Oct 2017 09:22:25 -0000

--94eb2c0749bea713ba055cd44ade
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>

<featuresProcessing xmlns=3D"
http://karaf.apache.org/xmlns/features-processing/v1.0.0">

    <!--
        org.apache.karaf.features.internal.service.RepositoryCache will
refuse to add/track a repository URI if it's blacklisted,
        either if added explicitly or as referenced features repository URI
    -->
    <blacklistedRepositories>

<repository>mvn:org.hibernate/hibernate-validator-osgi-karaf-features/5.*/x=
ml/features</repository>
        <!-- ... -->
    </blacklistedRepositories>

    <!--
        org.apache.karaf.features.internal.service.RepositoryCache will
transform added/tracked repository by removing blacklisted features
    -->
    <blacklistedFeatures>
        <feature>*jetty*</feature>
        <!-- ... -->
    </blacklistedFeatures>

    <!--
        org.apache.karaf.features.internal.service.RepositoryCache will
transform added/tracked repository and remove all blacklisted
        bundles from all the features in the repository
    -->
    <blacklistedBundles>
        <bundle>mvn:commons-logging/*</bundle>
        <!-- ... -->
    </blacklistedBundles>

    <!--
        We can configure RepositoryCache to change
'dependency=3D"false|true"' flag on given bundles, features,
        repositories or globally
    -->
    <overrideBundleDependency>
        <!-- Override "dependency" flag for all bundles of all features for
given repository URI(s) -->
        <repository
url=3D"mvn:org.ops4j.pax.cdi/pax-cdi-features/*/xml/features"
dependency=3D"true" />
        <repository url=3D"mvn:*/xml/features" dependency=3D"true" />
        <!-- Override "dependency" flag for all bundles of given feature(s)
-->
        <feature name=3D"jclouds*" version=3D"[1,3)" dependency=3D"true" />
        <!-- Override "dependency" flag for given bundle(s) -->
        <bundle url=3D"mvn:javax.annotation/javax.annotation-api/*"
dependency=3D"true" />
    </overrideBundleDependency>

    <!--
        Knowing there are multiple bundles containing the same classes
(usually APIs), we can "translate"
        bundle location to completely different bundles
    -->
    <bundleReplacements>
        <bundle originalUri=3D"mvn:org.eclipse.jetty.orbit/javax.servlet/3.=
0*"

replacement=3D"mvn:org.apache.geronimo.specs/geronimo-servlet_3.0_spec/1.0"=
 />
        <!-- ... -->
    </bundleReplacements>

    <!--
        We can completely rewrite any feature deifnition, which may be
useful for features beyond our control or
        which are no longer maintained. This is expert setting and has to
be configured with care.
        We can add, remove and change all the items inside feature
definition
    -->
    <featureReplacememnts>
        <feature name=3D"pax-jsf-resources-support" description=3D"Provide
sharing of resources according to Servlet 3.0 for OSGi bundles and JSF"
version=3D"6.0.7">
            <feature version=3D"[6.0,6.1)">pax-jsf-support</feature>
            <bundle
dependency=3D"true">mvn:org.ops4j.pax.web/pax-web-resources-extender/6.0.7<=
/bundle>

<bundle>mvn:org.ops4j.pax.web/pax-web-resources-jsf/6.0.7</bundle>
        </feature>
        <!-- ... -->
    </featureReplacememnts>

</featuresProcessing>

What do you think?

regards
Grzegorz Grzybek

2017-10-30 15:08 GMT+01:00 Grzegorz Grzybek <gr.grzybek@gmail.com>:

> Hello
>
> Continuing my investigation of Processor mechanism for feature definition=
s
> (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" =E2=86=92
> "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.servic=
e.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
> =3D=3D=3D
> [1]: https://issues.apache.org/jira/browse/KARAF-5376
>

--94eb2c0749bea713ba055cd44ade--