[
https://issues.apache.org/jira/browse/OAK-10635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812638#comment-17812638
]
Manfred Baedke commented on OAK-10635:
--------------------------------------
See PR#1291 for an ad hoc solution of the given issue with the embedded classes
from oak-store-document.
I agree that there is no need for a general approach, since the embedding of
classes from packages that are not exported is quite an exotic thing to do.
> BundledTypeRegistry replace guava collection refs with facade
> -------------------------------------------------------------
>
> Key: OAK-10635
> URL: https://issues.apache.org/jira/browse/OAK-10635
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
> Affects Versions: 1.62.0
> Reporter: Mark Adamcin
> Priority: Minor
>
> The oak-shaded-guava bundle exports shaded guava packages with a version that
> is defined by google to match the version of the upstream artifact. While it
> is a semantic versioning scheme, it follows the API contract of the entire
> artifact, and does not distinguish API changes in included packages like
> .base and .collect at a granular level, which can result in otherwise
> avoidable OSGi wiring errors when references to guava types leak outside of
> the greater Oak API boundary, such as when classes are embedded or when guava
> types are explicitly referenced in signatures outside of oak-shaded-guava.
> oak-commons should endeavor to provide a stable facade API for the simpler
> parts of the guava library that are referenced at runtime by other oak
> bundles, such as newHashMap(), ImmutableList.copyOf(), Preconditions.check*,
> and perhaps Closer.
> One example I know of that could where I could benefit from this approach
> almost immediately is a project where I am embedding
> BundlingConfigInitializer and BundledTypesRegistry from oak-store-document in
> a customized repository configuration. When BundledTypesRegistry is embedded,
> it brings with it imports of ImmutableMap, Maps, and Sets from
> org.apache.jackrabbit.guava.common.collect. With the recent guava upgrade to
> 33.0.0 in OAK-10605 in 1.61-SNAPSHOT, the custom repository bundle fails to
> activate because the previous import-package bounds no longer match:
> {{org.apache.jackrabbit.guava.common.collect;version=[32.1.3,33).}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
