karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject "Dynamic" org.apache.karaf.features.internal.service.Overrides#override()
Date Thu, 14 Sep 2017 07:59:44 GMT

I'd like to discuss an idea. Currently *only*
method decides whether (during feature installation/provisioning) given
bundle/resource URI from a feature should be "overriden" by some slightly
different URI.

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

But the easy path scenario is usually not what happens in reality. For
example we may end up with these guava versions installed (real case):
 – mvn:com.google.guava/guava/15.0
 – mvn:com.google.guava/guava/16.0
 – mvn:com.google.guava/guava/16.0.1
 – mvn:com.google.guava/guava/17.0
 – mvn:com.google.guava/guava/18.0
 – mvn:com.google.guava/guava/19.0
 – mvn:com.google.guava/guava/20.0

And from what I've seen, «dependency="true"» is used correctly in majority
of cases, but even if two features from different projects combined in
single distro are used, the order of feature installation matters - we can
end up with either of the bundle with dependency="true" installed (e.g.,
commons-beanutils 1.9.2 or 1.9.3) - but still this can be handled by

and what if one feature uses
(camel-sjms2) and another one "mvn:javax.jms/javax.jms-api/2.0"
(karaf/jms)? These have different Symbolic-Names... This is problem with
many JavaEE APIs, where we have Javax bundles (where Oracle published a
bundle for API), SMX specs, Geronimo specs, JBoss specs etc.

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
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?

best regards
Grzegorz Grzybek

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message