Hi, I just worked on adding an IT to Sling Post Servlet https://github.com/apache/sling-org-apache-sling-servlets-post/pull/32/files but it became a classpath nightmare due to very old compile time dependencies which prevents running ITs leveraging Oak compatible with Java > 14 without patching it. For details on how I patched see https://github.com/apache/sling-org-apache-sling-servlets-post/pull/32/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R265.
The underlying issues are 1) Older Oak versions (1.22.x) are incompatible with Java > 14 (due to https://issues.apache.org/jira/browse/OAK-7358) 2) Newer Oak versions require new Jackrabbit API (which was relocated from JR2 to Oak coordinates) 3) Newer Oak versions require new JR2 artifacts like jackrabbit-jcr-commons (which are sometimes used in Sling as well) So the question is, can we upgrade the compile/runtime requirements to Jackrabbit/JR2 (2 and 3) artifacts which are compatible with an Oak version runnable on Oak? Currently we have the following Mock Oak versions: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/tags - 1.62.0 being the newest currently - 1.44.0/1.40.0 already being compatible with Java > 14 but quite outdated - Older versions not runnable on Java > 14. Which Oak version is a reasonable compromise to use a baseline which - runs on all recent Java LTS versions (at least Java 21) - is still compatible with older distributions? Oak itself only maintains 1.22 as LTS version and the newest one. Unfortunately Maven/IDE integrations don’t allow to fully decouple test and compile dependencies (https://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html) which forces us to balance IT with runtime requirements in this case. Although there are some workarounds provided those are not understood by IDEs and hard to maintain, therefore I would strongly suggest find a middle ground here and use compile time dependencies still working with recent Oak versions. WDYT? Konrad
