I've created https://issues.apache.org/jira/browse/KARAF-5376 to track this
regards
Grzegorz Grzybek
2017-09-14 11:58 GMT+02:00 Grzegorz Grzybek <gr.grzy...@gmail.com>:
> Thanks for answer
>
> 2017-09-14 11:40 GMT+02:00 Guillaume Nodet <gno...@apache.org>:
>>
>> 2017-09-14 9:59 GMT+02:00 Grzegorz Grzybek <gr.grzy...@gmail.com>:
>>
>> > By default we can use etc/overrides.properties file to instruct Karaf to
>> > install e.g., mvn:commons-beanutils/commons-beanutils/1.9.3 instead of
>> > 1.9.2, but can't tell it to use 1.9.0 instead of 1.8.3. Which is of course
>> > reasonable.
>> >
>>
>> Actually, this is only a default behavior. You can force this case using
>> mvn:commons-beanutils/commons-beanutils/1.9.3;range=[1.0,1.9.3)
>> which would replace any commons-beanutils in the range.
>> But I think that's slightly irrelevant with the rest of your email.
>
> Yes - I meant default behavior and at best - slightly configurable
> with "range" clause
>
>> >
>> > So my idea is to generalize "overrides" mechanism - change it into kind of
>> > features service hook and provide dedicated, explicit other mechanisms.
>> >
>> > For example I could create a maven plugin, that could use some input
>> > information about groupId:artifactId alternatives, some preconfigured
>> > overrides, etc. This maven plugin could be used at karaf-maven-plugin run
>> > time to generate additional ("compiled") file acting as enhanced
>> > etc/overrides.properties.
>> > And this file could be read/used by features service "hook", which could
>> > not only (as Overrides.shouldOverride() does) "translate" bundle URIs, but
>> > change entire features during installation:
>> > – add some new bundles (configs?) to a feature
>> > – use different groupId:artifactId of <bundle>
>> > – skip some bundle
>> > – ...
>> >
>> > Currently Karaf features are NOT like Maven dependencies - Maven builds
>> > transitive graph of dependencies and may choose between deps with same
>> > groupId:artifactId and different version.
>> >
>> > With my "hook" idea, static feature definition from *-features.xml file
>> > would only be a "declaration" of a feature, which MAY be changed at
>> > runtime.
>> >
>> > I imagine that it's not that trivial and features service has huge runtime
>> > part (resolver) that would be (would it?) affected, but I'd like to know
>> > what do you think?
>> >
>>
>> I'm not entirely sure what you have in mind, but what could be quite simple
>> to implement, without requiring any real resolver change, would be a
>> service that pre-processes a set of features just before it's used by the
>> resolver.
>
> Exactly - I meant kind of "phase" after reading feature descriptors
> from XML and before passing them to resolver.
>
>> The features set is an input to the resolver, it's currently stored at the
>> following location:
>>
>> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/Deployer.java#L168
>>
>> In a usual scenario, the values comes from the following:
>>
>> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/FeaturesServiceImpl.java#L596-L599
>>
>> What can be easily achieved, is to pre-process this set through a service
>> with a simple interface such as
>> interface FeaturesProcessor {
>> Map<String, Feature> process(Map<String, Feature> features);
>> }
>>
>> Note that we also have a different mechanism that has an effect on features
>> at runtime, it's the blacklisting policy.
>> The difference is that this one is actually done when the repositories are
>> loaded:
>>
>> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/RepositoryImpl.java#L85
>
> The blacklisting of features/repositories could be part of this
> dynamic postprocessing.
>
>>
>> The difference is also because, given the overrides mechanism uses the
>> resource symbolic name + version to see if an override should take place,
>> it has to actually load the resources, and *then* eventually override it.
>
> As above - "overrides" could stay as is (possibly changed to hooked
> version instead of static dependency) as "postprocessor that requires
> resource manifest access"
>
>>
>> Anyway, big +1 to investigate something around that, as I think it is
>> clearly missing.
>> This may also indicates that the fact that application development and
>> deployment are somewhat conflated in the same xml feature repository need
>> to be revisited somehow.
>
> I'm trying to find analogies with Maven. And we did it countless times
> - when library developer publishes not-so-good POM, we can try
> <exclude> some wrong
> dependencies or override versions. I meant to create something for
> features - original author could declare the "rough" feature, but
> given runtime (e.g., Karaf with clever hooks) could postprocess these
> "feature declarations".
>
> I'll have a look at the idea and try to prepare some draft solution.
>
> regards Grzegorz Grzybek
