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
