ci: run the integration tests through failsafe and verify the shaded jar

[LuciferYang]

What this does

The repo has five *ITCase classes and none of them had ever run. There is no maven-failsafe-plugin in the build, and *ITCase does not match surefire's default includes (*Test, *Tests, *TestCase), so mvn verify walked straight past them. #55 listed this as a follow-up; this is it.

Four changes:

1. Wire maven-failsafe-plugin into the three jar modules so verify runs the ITs.
2. Add LanceShadedJarITCase, for the reason in the next section.
3. Set argLine so Arrow can allocate off-heap on JDK 17+, which is what turning the ITs on immediately exposed.
4. In the workflow, rename the build step and widen the failure artifact so it carries the failsafe reports next to surefire's. The mvn command does not change: verify now covers the ITs, so the existing 8-job matrix picks them up as it stands.

Why failsafe has to target target/classes

maven-shade-plugin relocates org.apache.arrow to org.apache.flink.connector.lance.shaded.arrow at package, replacing the main artifact. failsafe defaults to that main artifact. The tests compile against plain Arrow, so running them against the shaded jar fails with NoSuchMethodError: the signatures moved.

target/classes                    -> toArrowSchema(RowType) : org.apache.arrow.vector.types.pojo.Schema
target/lance-flink-1.18-0.1.0.jar -> toArrowSchema(RowType) : org.apache.flink.connector.lance.shaded.arrow.vector.types.pojo.Schema

Hence <classesDirectory>${project.build.outputDirectory}</classesDirectory>. The cost is that the shaded jar, which is what users actually deploy, then has no automated check at all. That is what LanceShadedJarITCase covers: it loads the jar in its own classloader and asserts that no plain-Arrow class is bundled, and that the connector's public signatures reference the relocated packages.

Guarding against silent no-ops

Three ways a green build could have stopped proving the ITs ran, all closed here:

• Listing any <includes> pattern replaces failsafe's whole default set, and failIfNoTests defaults to false, so a pattern matching nothing exits 0. The defaults are restated and failIfNoTests is on.
• The shaded-jar check first probed a single class name. A per-package relocation carve-out, which is the usual fix when a JNI package breaks on being moved, leaves plain Arrow in the jar while that one class still resolves. It now walks every jar entry.
• A missing jar was an assumeTrue, so it skipped. shade runs at package, before this phase, so if the build handed us a path the jar should be there. It asserts now.

failsafe hangs off the three jar modules rather than the root aggregator, since the root has no test classes of its own and failIfNoTests=true would fail it there.

Why one matrix rather than separate IT jobs

Giving the ITs their own jobs is the obvious shape and it does not pay off here, because a job in the existing matrix already does everything the ITs need. Here is a -DskipITs job, Flink 1.18 / JDK 17, by phase:

surefire:test               19:48:57
jar:jar                     19:49:05
shade:shade                 19:49:05    <- 280MB fat jar, built anyway
failsafe:integration-test   19:49:43    <- "Tests are skipped."

-DskipITs skips failsafe and nothing else. The reactor compile and the shade run either way, and failsafe's own 44 tests take 4.7 seconds. So a dedicated IT job would pay for a second full build to buy 4.7 seconds of coverage, and the overlap would grow with every unit test added.

Keeping them in the existing matrix also widens IT coverage from one JDK to all eight Flink x JDK combinations. The JDK axis is not idle for ITs: the MemoryUtil failure below reproduces on 17+ and only warns on 11. The eight jobs on this branch run 57 to 77 seconds each.

Test plan

mvn -am -pl lance-flink-<v> verify was run locally for every Flink x JDK pair the matrix covers, and all eight report 44 ITs and 186 unit tests:

	JDK 11	JDK 17	JDK 21
1.18	44	44	not in matrix
1.19	44	44	44
1.20	44	44	44

44 = LanceSqlITCase 20 + LanceConnectorITCase 15 + LanceTimeTravelITCase 4 + LanceNamespaceCatalogITCase 3 + LanceShadedJarITCase 2. One of the time-travel cases is an opt-in export gated on $TT_EXPORT_DIR and reports as skipped, so a green run shows Skipped: 1. -DskipITs still works for a local unit-only run, verified on 1.18/JDK 17 and 1.20/JDK 21.

Both new checks were reverse-verified by breaking what they watch:

• Comment out shade's <relocations> and LanceShadedJarITCase goes red (1 failure, 1 error).
• Add <exclude>org.apache.arrow.memory.**</exclude> to the relocation and the jar-walk assertion fails, listing the leaked org/apache/arrow/memory/*.class entries. The single-class probe stayed green on this one, which is why it was replaced.
• Point -Dfailsafe.includes at a pattern matching nothing and the build fails, where before failIfNoTests it exited 0.

What the ITs found

LanceTimeTravelITCase, which came in with #56, errored on three of its four cases as soon as failsafe started running it:

Failed to initialize MemoryUtil. You must start Java with
  --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED

It writes real Arrow vectors, and Arrow reaches java.nio.Buffer.address by reflection. JDK 17 blocks that outright, so MemoryUtil's static initializer throws and the tests fail with NoClassDefFoundError. JDK 11 only prints an illegal-reflective-access warning, which is part of why this went unnoticed: nothing was running the class on any JDK.

Fixed by setting argLine as a root property. Arrow's own poms carry the same flag for their test runs. Keeping it a property rather than putting it inside surefire's <configuration> is what keeps jacoco working, since prepare-agent appends its -javaagent to argLine instead of replacing it. The build log confirms both survive:

argLine set to -javaagent:.../org.jacoco.agent-0.8.14-runtime.jar=destfile=... --add-opens=java.base/java.nio=ALL-UNNAMED

[LuciferYang]

cc @fightBoxing

[LuciferYang]

cc @fightBoxing