OAK-12251: Consolidate test-scoped dependencies (Mockito, JUnit extras)

[bhabegger]

Centralises test dependency declarations in oak-parent dependencyManagement under a dedicated Test dependencies section, making it the single place to manage test library versions across all modules.

What changes:

• Moves JUnit (4.13.1 / JUnit BOM 5.14.2), Mockito, EasyMock, slf4j-simple, OSGi mocks, Testcontainers, pax-exam transitives, and misc test utilities into an explicit test-scoped dependencyManagement section.
• Extracts a mockito.version property (5.23.0) and pins Mockito's runtime transitives (byte-buddy, objenesis, asm) to matching versions.
• Pins pax-exam transitives (pax-swissbox-tracker 1.9.0, tinybundles 3.0.0, pax-url-commons) for deterministic resolution.
• Removes redundant inline version declarations from oak-jcr, oak-lucene, oak-run, oak-run-commons, oak-search-elastic, oak-store-document, and oak-segment-azure — those modules now inherit versions from the parent.

Scope: test infrastructure only; no changes to production code or OSGi bundle manifests.

JIRA: https://issues.apache.org/jira/browse/OAK-12251

[bhabegger]

Moved, not removed, to group test dependencies together at end of depdendencyManagement.

[reschke]

https://issues.apache.org/jira/browse/OAK-12251?focusedCommentId=18088232&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18088232

Frankly: I see almost nothing to do here.

Consolidating transitive test dependencies is actually pointless or hamful:

they vary with the dependency they come from; and that might actually be by design or needed

when they change: removal - we are left with noise in the parent pom; version change: we would actually have the incorect version.

That sounds like a maintenance nightmare to me.

[reschke]

(I believe this ticket should be closed as "Won't Do")

[bhabegger]

https://issues.apache.org/jira/browse/OAK-12251?focusedCommentId=18088232&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18088232

Frankly: I see almost nothing to do here.

Consolidating transitive test dependencies is actually pointless or hamful:

they vary with the dependency they come from; and that might actually be by design or needed

when they change: removal - we are left with noise in the parent pom; version change: we would actually have the incorect version.

That sounds like a maintenance nightmare to me.

Well, why not try it and see? Because from my experience managing dependencies is not such of nightmare at all, quite the contrary.

[bhabegger]

And if it's such a crazy idea, why would this even exist ?
https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

And more, so why do projects rely on it ?
I've worked on projects where this is in place and it solves more issues than it creates.

[reschke]

And if it's such a crazy idea, why would this even exist ?

Ahem? Seriously???

The problem is that scanners like these tend to report false positives. Uncritically acting on these actually can cause new problems, not to mention it creates noise in the POMs which is hard to maintain. Such as excluding things that might go away anyway (transitive Guava dependencies, for instance). Or considering annotation processors (errorprone) that are only used at compile time of the dependency.