karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grzegorz Grzybek (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KARAF-5376) Processor mechanism for feature definitions (a.k.a. "better overrides")
Date Tue, 10 Apr 2018 08:49:00 GMT

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

Mime
View raw message