karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: "Dynamic" org.apache.karaf.features.internal.service.Overrides#override()
Date Thu, 14 Sep 2017 09:58:10 GMT
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 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

Mime
View raw message