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: <CAAdXmho8cjSKeTswvcF17Bs6rEMUwinKDG_+Bm=4Q-e8A2byMw@mail.gmail.com>
References: <CAAdXmho8cjSKeTswvcF17Bs6rEMUwinKDG_+Bm=4Q-e8A2byMw@mail.gmail.com>
From: Grzegorz Grzybek <gr.grzybek@gmail.com>
Date: Thu, 14 Sep 2017 12:09:05 +0200
Message-ID: <CAAdXmhqByBhuWWkSRvH4FbWoYT9F_OH6PacYh5GhHHLf_CpMQA@mail.gmail.com>
Subject: Re: "Dynamic" org.apache.karaf.features.internal.service.Overrides#override()
To: dev@karaf.apache.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 14 Sep 2017 10:09:12 -0000

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.grzybek@gmail.com>:
> Thanks for answer
>
> 2017-09-14 11:40 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:
>>
>> 2017-09-14 9:59 GMT+02:00 Grzegorz Grzybek <gr.grzybek@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 co=
urse
>> > reasonable.
>> >
>>
>> Actually, this is only a default behavior. You can force this case using
>>  mvn:commons-beanutils/commons-beanutils/1.9.3;range=3D[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 kin=
d 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 cou=
ld
>> > not only (as Overrides.shouldOverride() does) "translate" bundle URIs,=
 but
>> > change entire features during installation:
>> >  =E2=80=93 add some new bundles (configs?) to a feature
>> >  =E2=80=93 use different groupId:artifactId of <bundle>
>> >  =E2=80=93 skip some bundle
>> >  =E2=80=93 ...
>> >
>> > Currently Karaf features are NOT like Maven dependencies - Maven build=
s
>> > 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 fil=
e
>> > 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 run=
time
>> > part (resolver) that would be (would it?) affected, but I'd like to kn=
ow
>> > what do you think?
>> >
>>
>> I'm not entirely sure what you have in mind, but what could be quite sim=
ple
>> 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 th=
e
>> 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 t=
he
>> 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-L5=
99
>>
>> What can be easily achieved, is to pre-process this set through a servic=
e
>> 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 featu=
res
>> at runtime, it's the blacklisting policy.
>> The difference is that this one is actually done when the repositories a=
re
>> 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 nee=
d
>> 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