Hi JB, Would of course be great if versions would always be in sync, but may be difficult to achieve. My solution is currently to create small projects with adapted feature files and use these for a custom assembly. Of course, that means relying on libraries strictly following the rules of semantic versioning and not introducing breaking changes when incrementing the minor version.
I may have found an old ticket for that: https://issues.apache.org/jira/browse/KARAF-6068. Could it be that when running into the timeout mentioned there, some package exports may also be missing? Is so, a log output at least on WARN level would be helpful. Thanks & Regards Jochen Am 21. September 2023 10:41:19 MESZ schrieb "Jean-Baptiste Onofré" <[email protected]>: >Hi, > >I think you have two options: >- you can blacklist from the features. >- you can override the features > >Generally speaking, it would be great that third parties features >leverage the Karaf spec features to avoid such kind of issue. > >I will do a pass (it's weird that our unit tests passed without problem). > >Regards >JB > >On Wed, Sep 20, 2023 at 7:45 PM Jochen Walz ><[email protected]> wrote: >> >> Hello, >> >> with Karaf 4.4.4, the bouncycastle version has changed to 1.75. CXF >> still uses 1.70, i.e. when installing the CXF 3.6.2 feature, two >> versions of bcprov are installed. With a debug level log appender >> defined for org.apache.felix.resolver or setting the log level of the >> root logger to DEBUG, this leads to multiple log entries like >> >> >> 2023-09-20T12:46:12,788 | DEBUG | features-3-thread-1 | >> ResolverImpl | 17 - org.apache.karaf.features.core - >> 4.4.4 | Candidate permutation failed due to a conflict between imports; >> will try another if possible. (Uses constraint violation. Unable to >> resolve resource io.netty.handler [io.netty.handler/4.1.97.Final] >> because it is exposed to package 'org.bouncycastle.asn1.pkcs' from >> resources bcprov [bcprov/1.70.0] and bcprov [bcprov/1.75.0] via two >> dependency chains. >> >> Chain 1: >> io.netty.handler [io.netty.handler/4.1.97.Final] >> import: >> (&(osgi.wiring.package=org.bouncycastle.asn1.pkcs)(version>=1.69.0)(!(version>=2.0.0))) >> | >> export: osgi.wiring.package: org.bouncycastle.asn1.pkcs >> bcprov [bcprov/1.70.0] >> >> Chain 2: >> io.netty.handler [io.netty.handler/4.1.97.Final] >> import: >> (&(osgi.wiring.package=org.bouncycastle.cert)(version>=1.69.0)(!(version>=2.0.0))) >> | >> export: osgi.wiring.package=org.bouncycastle.cert; >> uses:=org.bouncycastle.asn1.x509 >> bcpkix [bcpkix/1.75.0] >> import: >> (&(osgi.wiring.package=org.bouncycastle.asn1.x509)(version>=1.72.0)) >> | >> export: osgi.wiring.package: org.bouncycastle.asn1.x509; >> uses:=org.bouncycastle.asn1.pkcs >> export: osgi.wiring.package=org.bouncycastle.asn1.pkcs >> bcprov [bcprov/1.75.0]) ... >> >> >> and >> >> >> 2023-09-20T12:46:13,779 | DEBUG | features-3-thread-1 | >> ResolverImpl | 17 - org.apache.karaf.features.core - >> 4.4.4 | Candidate permutation failed due to a conflict between imports; >> will try another if possible. (Uses constraint violation. Unable to >> resolve resource com.fasterxml.jackson.core.jackson-databind >> [com.fasterxml.jackson.core.jackson-databind/2.14.1] because it is >> exposed to package 'com.fasterxml.jackson.core.base' from resources >> com.fasterxml.jackson.core.jackson-core >> [com.fasterxml.jackson.core.jackson-core/2.14.1] and >> com.fasterxml.jackson.core.jackson-core >> [com.fasterxml.jackson.core.jackson-core/2.15.2] via two dependency chains. >> >> Chain 1: >> com.fasterxml.jackson.core.jackson-databind >> [com.fasterxml.jackson.core.jackson-databind/2.14.1] >> import: >> (&(osgi.wiring.package=com.fasterxml.jackson.core.base)(version>=2.14.0)(!(version>=3.0.0))) >> | >> export: osgi.wiring.package: com.fasterxml.jackson.core.base >> com.fasterxml.jackson.core.jackson-core >> [com.fasterxml.jackson.core.jackson-core/2.14.1] >> >> Chain 2: >> com.fasterxml.jackson.core.jackson-databind >> [com.fasterxml.jackson.core.jackson-databind/2.14.1] >> import: >> (&(osgi.wiring.package=com.fasterxml.jackson.core)(version>=2.14.0)(!(version>=3.0.0))) >> | >> export: osgi.wiring.package=com.fasterxml.jackson.core; >> uses:=com.fasterxml.jackson.core.json >> com.fasterxml.jackson.core.jackson-core >> [com.fasterxml.jackson.core.jackson-core/2.15.2] >> import: >> (&(osgi.wiring.package=com.fasterxml.jackson.core.json)(version>=2.15.0)(!(version>=3.0.0))) >> | >> export: osgi.wiring.package=com.fasterxml.jackson.core.json; >> uses:=com.fasterxml.jackson.core.base >> com.fasterxml.jackson.core.jackson-core >> [com.fasterxml.jackson.core.jackson-core/2.15.2] >> import: >> (&(osgi.wiring.package=com.fasterxml.jackson.core.base)(version>=2.15.0)(!(version>=3.0.0))) >> | >> export: osgi.wiring.package: com.fasterxml.jackson.core.base >> com.fasterxml.jackson.core.jackson-core >> [com.fasterxml.jackson.core.jackson-core/2.15.2]) ... >> >> >> It may take very long until the resolver finishes. In some cases, it >> obviously fails at this point, and later I receive some FileNotFound >> exceptions because some packages are not exported - I have observed >> this, e.g., for the Datastax Cassandra driver, version 4.17, when >> jackson-databind 2.14.1 and 2.15.2 are both installed. The behavior is >> not always reproducible. E.g., for a feature with a bundle importing >> some bouncycastle packages, installation of the feature takes very long >> and/or finally fails, while installing and starting the bundles one by >> one succeeds. >> >> I don't think this is specifically related to 4.4.4 - only showed up in >> my case due to the upgraded dependencies while other features are still >> using older ones. >> >> Does anybody have an idea how to solve that? >> >> Thanks & Regards >> >> Jochen >>
