Hi Jochen Not sure if KARAF-6068 is exactly the same, but it seems pretty close. Let me create a test case to improve it (at least with WARN message).
Thanks Regards JB On Sat, Sep 23, 2023 at 10:52 AM Jochen Walz <[email protected]> wrote: > > 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 >>>
