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:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <featuresProcessing xmlns="
> 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.*/xml/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="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="mvn:org.ops4j.pax.cdi/pax-cdi-features/*/xml/features"
> dependency="true" />
>         <repository url="mvn:*/xml/features" dependency="true" />
>         <!-- Override "dependency" flag for all bundles of given feature(s)
> -->
>         <feature name="jclouds*" version="[1,3)" dependency="true" />
>         <!-- Override "dependency" flag for given bundle(s) -->
>         <bundle url="mvn:javax.annotation/javax.annotation-api/*"
> dependency="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="mvn:org.eclipse.jetty.orbit/javax.servlet/3.0*"
>
> replacement="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="pax-jsf-resources-support" description="Provide
> sharing of resources according to Servlet 3.0 for OSGi bundles and JSF"
> version="6.0.7">
>             <feature version="[6.0,6.1)">pax-jsf-support</feature>
>             <bundle
> dependency="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.grzy...@gmail.com>:
>
>> 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
>>

Reply via email to