I do understand the reasoning for the change, but I take issue with breaking changes making it into a stable point release.
To further test, I removed all Guava code from my application and removed the explicit dependency of Guava in my POM. Everything compiles again, but now I receive a different runtime exception: "Caused by: java.lang.ClassNotFoundException: com.google.common.cache.Weigher". It seems to be failing on the line where I call "MongoDocumentNodeStoreBuilder.newMongoDocumentNodeStoreBuilder().." Is it possible the dependency is not actually compile only, and it is indeed needed at runtime? I ran "mvn dependency:tree" and don't see Guava listed anywhere. Thanks, Jesse On Thu, Jan 19, 2023 at 1:27 PM Julian Reschke <julian.resc...@gmx.de> wrote: > On 19.01.2023 17:09, Jesse wrote: > > After updating the pom.xml for my application from JCR-OAK 1.44.0 to > > 1.46.0, my application failed to compile due to the Guava library not > being > > found. I also see from the 1.46 changelog: > > > > [OAK-9994] - avoid leaking out transitive dependencies to Guava > > > > I assumed the dependency was no longer automatically resolved, so I added > > an entry for the latest Guava version 31.1-jre, and the code compiles > > again. However it looks like JCR oak needs a specific version of Guava to > > function correctly, or it will fail. (If I change the version to 15.0, it > > works). > > > > I'm not sure what the intent of all the changes are in this release, but > I > > think the old behavior of providing the dependency of the version > required > > by oak is the better approach. > > ... > > This is all expected, intentionally, and described in > <https://issues.apache.org/jira/browse/OAK-9994>. > > Best regards, Julian >
