[jira] [Comment Edited] (KARAF-5376) Processor mechanism for feature definitions (a.k.a. "better overrides")

["Grzegorz Grzybek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KARAF-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431939#comment-16431939 ] 

Grzegorz Grzybek edited comment on KARAF-5376 at 4/10/18 8:48 AM:
------------------------------------------------------------------

Here's a quick description (I really plan to provide exhaustive documentation) of the changed mechanism.

Fundamentally, Karaf's Feature Service has been extended (in features model and in provisioning/resolution parts):
* feature, bundle and repository JAXB classes contain "blacklisted" flags and (in case of bundles) and "original URI" for the purposes of overriding (which is much more than we had with {{etc/overrides.properties}}
* features service, after reading features model from e.g., {{mvn:org.apache.cxf.karaf/apache-cxf/3.1.11/xml/features}} *processes it* using instructions contained in {{etc/org.apache.karaf.features.xml}}
* {{etc/org.apache.karaf.features.xml}} may contain instructions to:
** blacklist repositories, features and bundles (by _pattern_)
** override bundles (both within the same groupId/artifactId and entirely different - for example you can tell features service this:
{code:xml}
<bundle originalUri="mvn:javax.mail/mail/[1.4,1.5)"
        replacement="mvn:com.sun.mail/javax.mail/1.6.1" mode="maven" />
{code}
** override even entire feature definitions! so if you see some no-longer maintained feature file (like jclouds) contains some bundle you don't want, you can override entire feature definition. I did it for example with broken hibernate-validator feature ([https://hibernate.atlassian.net/browse/HV-1429]):
{code:xml}
<!-- A list of feature replacements that allows changing external feature definitions -->
<featureReplacements>
    <replacement>
        <feature name="hibernate-validator-paranamer" version="${version.org.hibernate.validator}">
            <f:feature>hibernate-validator</f:feature>
            <f:bundle>wrap:mvn:com.thoughtworks.paranamer/paranamer/${version.com.thoughtworks.paranamer}</f:bundle>
        </feature>
    </replacement>
</featureReplacements>
{code}
(original uses {{wrap:mvn:com.thoughtworks.paranamer:paranamer:}} instead of {{wrap:mvn:com.thoughtworks.paranamer/paranamer/}}
* {{etc/org.apache.karaf.features.xml}} may be provided by you in the KAR that's foundation of your custom distro or may be generated from {{<blacklistedRepositories>}}, {{<blacklistedFeatures>}} and {{<blacklistedBundles>}} configuration options of {{karaf-maven-plugin}}.
* Additionall, in Karaf 4.2.0 features may be blacklisted with glob patterns (KARAF-5273), {{mvn:}} based bundle and repository URIs may be blacklisted using version ranges and non {{mvn:}} bundle and repository URIs may be blacklisted using globs.


was (Author: gzres):
Here's a quick description (I really plan to provide exhaustive documentation) of the changed mechanism.

Fundamentally, Karaf's Feature Service has been extended (in features model and in provisioning/resolution parts):
* feature, bundle and repository JAXB classes contain "blacklisted" flags and (in case of bundles) and "original URI" for the purposes of overriding (which is much more than we had with {{etc/overrides.properties}}
* features service, after reading features model from e.g., {{mvn:org.apache.cxf.karaf/apache-cxf/3.1.11/xml/features}} *processes it* using instructions contained in {{etc/org.apache.karaf.features.xml}}
* {{etc/org.apache.karaf.features.xml}} may contain instructions to:
** blacklist repositories, features and bundles (by _pattern_)
** override bundles (both within the same groupId/artifactId and entirely different - for example you can tell features service this:
{code:xml}
<bundle originalUri="mvn:javax.mail/mail/[1.4,1.5)"
        replacement="mvn:com.sun.mail/javax.mail/1.6.1" mode="maven" />
{code}
** override even entire feature definitions! so if you see some no-longer maintained feature file (like jclouds) contains some bundle you don't want, you can override entire feature definition. I did it for example with broken hibernate-validator feature (https://hibernate.atlassian.net/browse/HV-1429):
{code:xml}
<!-- A list of feature replacements that allows changing external feature definitions -->
<featureReplacements>
    <replacement>
        <feature name="hibernate-validator-paranamer" version="${version.org.hibernate.validator}">
            <f:feature>hibernate-validator</f:feature>
            <f:bundle>wrap:mvn:com.thoughtworks.paranamer/paranamer/${version.com.thoughtworks.paranamer}</f:bundle>
        </feature>
    </replacement>
</featureReplacements>
{code}
(original uses {{wrap:mvn:com.thoughtworks.paranamer:paranamer:}} instead of {{wrap:mvn:com.thoughtworks.paranamer/paranamer/}}
* {{etc/org.apache.karaf.features.xml}} may be provided by you in the KAR that's foundation of your custom distro or may be generated from {{<blacklistedRepositories>}}, {{<blacklistedFeatures>}} and {{<blacklistedBundles>}} configuration options of {{karaf-maven-plugin}}.
* Additionall, in Karaf 4.2.0 features may be blacklisted with glob patterns (KARAF-5273), {{mvn:}} based bundle and repository URIs may be blacklisted using version ranges and non {{mvn:}} bundle and repository URIs may be blacklisted using globs.

> Processor mechanism for feature definitions (a.k.a. "better overrides")
> -----------------------------------------------------------------------
>
>                 Key: KARAF-5376
>                 URL: https://issues.apache.org/jira/browse/KARAF-5376
>             Project: Karaf
>          Issue Type: Proposal
>          Components: karaf-feature
>            Reporter: Grzegorz Grzybek
>            Assignee: Grzegorz Grzybek
>            Priority: Major
>             Fix For: 4.2.0.M2
>
>
> It'd be good to have a mechanism that could transform/enhance/process feature definitions after reading them from original feature XML descriptors and before passing them to Karaf features deployer.
> Current overrides mechanism could be generalized beyond simple version change for {{<feature>/<bundle>}} URIs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)