karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Estermann <ester...@apache.org>
Subject FeaturesProcessorImpl improvement of bundle override
Date Tue, 05 Mar 2019 17:19:38 GMT
Hi everybody,

we have the following override.properties:

mvn:com.seeburger.portal/portal-backend-sdk/2.69.0-SNAPSHOT;range="[0,99999)"
mvn:com.seeburger.portal/portal-backend-sdk/2.69.0-SNAPSHOT/jar/karaf-migration;range="[0,99999)"

which are supposed to do the following replacements:

portal-backend-sdk/2.68.3 -> portal-backend-sdk/2.69.0-SNAPSHOT

and

portal-backend-sdk/2.68.3/jar/karaf-migration ->
portal-backend-sdk/2.69.0-SNAPSHOT/jar/karaf-migration

But the method
org.apache.karaf.features.internal.service.FeaturesProcessorImpl.staticOverrideBundle(Bundle)
<https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/FeaturesProcessorImpl.java#L225>
replaces portal-backend-sdk/2.68.3/jar/karaf-migration with
mvn:com.seeburger.portal/portal-backend-sdk/2.69.0-SNAPSHOT, i.e. a
classified artifact gets replaced with an artifact without classifier. This
happens because the implementation of
org.apache.karaf.features.LocationPattern
<https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/LocationPattern.java#L151>
allows matching of classified URI by a non-classified pattern. The
LocationPatternTest indicates that this is an intentional behavior: see
line 112
<https://github.com/apache/karaf/blob/master/features/core/src/test/java/org/apache/karaf/features/internal/service/LocationPatternTest.java#L112>,
115
<https://github.com/apache/karaf/blob/master/features/core/src/test/java/org/apache/karaf/features/internal/service/LocationPatternTest.java#L115>,
116
<https://github.com/apache/karaf/blob/master/features/core/src/test/java/org/apache/karaf/features/internal/service/LocationPatternTest.java#L116>
.

I can understand why LocationPattern is implemented like that. But then my
guess is that FeaturesProcessorImpl is incorrect. By the way an interesting
comment there: *TOCHECK: last rule wins - no break!!!* Last rule doesn't
work for us so looks like now the time has come to check it. I think what
is crucial there, is that we shouldn't rely on the order of overrides, but
rather on their quality. I.e. not the first/last match is appropriate, but
the best one. I propose to collect candidates to match and then determine
the best one using simply the length as criterion.

My proposal is already implemented in our fork and tested on my local
system (for now). Here you can see it:
https://github.com/seeburger-ag/karaf/commit/940911e8a8ccdb97d5cebf976e41747f1e7716a4

I would appreciate to receive any feedback on this.

Regards,
Daniel

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