Point AutoValue invoker at value/src/it for functional tests

[tanvir-ux]

Summary

• The maven-invoker-plugin on value/processor defaulted to processor/src/it, so the functional IT projects under value/src/it (and the eclipse profile pass from invoker.properties) never ran.
• Set projectsDirectory to ${project.parent.basedir}/src/it so invoker picks them up again.

Fixes #1558

Test plan

• mvn -pl value/processor -am verify (or the repo build-pom.xml verify job) runs the functional invoker projects

[cpovirk]

The Auto build has always been too much of a mystery to me. I kicked off CI, which shows:

[INFO] [ERROR] Failed to execute goal on project gwtserializer: Could not resolve dependencies for project com.google.auto.value.it.gwtserializer:gwtserializer:jar:HEAD-SNAPSHOT
[INFO] [ERROR] dependency: com.google.auto.value:auto-value-annotations:jar:HEAD-SNAPSHOT (compile)
[INFO] [ERROR] 	Could not find artifact com.google.auto.value:auto-value-annotations:jar:HEAD-SNAPSHOT

[tanvir-ux]

@cpovirk yeah — pointing at value/src/it made invoker pick up gwtserializer too (that’s a JDK11+ reactor module, not an invoker IT). Also invoker:install defaults to runtime scope, so test-scoped auto-value-annotations never got staged into it-repo.

Fix in value/processor/pom.xml:

• pomIncludes → only functional/pom.xml
• invoker.install.scope=test so annotations lands in the IT repo

Pushed; CI should re-run.

[tanvir-ux]

(also: the new CI run is sitting on action_required for the fork — same as before, needs a maintainer approve/kick)

[cpovirk]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-invoker-plugin:3.10.1:install (integration-test) on project auto-value: The following artifacts could not be resolved: com.sun:tools:pom:1.8.0_504 (absent): Could not find artifact com.sun:tools:pom:1.8.0_504 in central (https://repo.maven.apache.org/maven2) -> [Help 1]

[tanvir-ux]

@cpovirk thanks — that was from invoker.install.scope=test, which also tried to install compile-testing's transitive com.sun:tools (the old JDK tools.jar), and that POM isn't on Central.

I dropped the broad test-scope install and stage only auto-value-annotations via extraArtifacts instead. Pushed in 29282c9. CI will need another maintainer kick/approve on the fork run when you have a moment.

[eamonnmcmanus]

Thanks for looking into this!

However, I'm not seeing any evidence from the logs that value/ functional tests other than the gwtserializer ones are actually being run. For example AutoValueTest. A good check would be to introduce a call to fail() in one of the test methods there. Then the mvn command from the CI should fail.

[cpovirk]

Sigh, sorry, thanks for checking that :(

[tanvir-ux]

@eamonnmcmanus thanks — looking into this now. I'll verify that the value/src/it/functional suite (including AutoValueTest) actually runs under the CI mvn command, and push a fix if the invoker path still isn't picking it up.

[tanvir-ux]

@eamonnmcmanus good catch — you were right that AutoValueTest wasn't actually executing.

CI on the previous HEAD was compiling value/src/it/functional (and the invoker clone) but Surefire reported Tests run: 0. Cause: gradle-test-kit puts JUnit Jupiter on the test classpath, so Surefire 3.x auto-selects JUnitPlatformProvider and skips the JUnit 4 suite (AutoValueTest et al.). gwtserializer doesn't pull Jupiter, which is why those tests still showed up.

Pushed a fix on this branch: pin surefire-junit4 on the functional module (and the same provider on failsafe for GradleIT). After CI re-runs you should see Running com.google.auto.value.AutoValueTest in the logs. Fork workflows may need another approve/kick when you have a moment.

[tbroyer]

Fwiw, Surefire 3.6 removes surefire-junit4 and always uses Jupiter (running Junit 4 tests with the Vintage engine)
https://maven.apache.org/surefire/maven-surefire-plugin/whats-new-3-6-0.html

So maybe it'd be best to first upgrade to 3.6 (#2134) and then reevaluate how to get the tests to run (if this doesn't directly fix it)

[cpovirk]

(approving workflows again, though I am hoping to ultimately wait for #2134 and then revert the final commit)

[tanvir-ux]

@eamonnmcmanus @tbroyer follow-up: switched the functional IT to Surefire/Failsafe 3.6.0 plus junit-vintage-engine (and dropped the temporary junit4 provider pin).

That matches the Surefire 3.6 direction — Jupiter always, JUnit 4 via Vintage — so AutoValueTest should actually run once CI is kicked on the fork. Happy to adjust further if the logs still look wrong.

[cpovirk]

Local testing showed:

• TestEngine with ID 'junit-jupiter' failed to discover tests
• or, if I remove the junit-vintage-engine configuration (leaving only the plugin bumps and the maven-invoker-plugin change), the problem solved by Skip more tests under Java 8. #2140

So I pushed a merge commit. I'll trigger workflows now and see what happens, and I'll retest locally without the junit-vintage-engine configuration.

[cpovirk]

CI shows the expected "failed to discover tests" error.

Local testing without the junit-vintage-engine configuration passes. I'm now checking that it fails when appropriate as described above.

Does it seem reasonable that we'd be able to ultimately revert value/src/it/functional/pom.xml once #2142 is incorporated?

[tanvir-ux]

@cpovirk yes — that sounds right.

In fact I just dropped the value/src/it/functional/pom.xml Surefire 3.6 / junit-vintage-engine pin entirely (cb7c910). Your local result matches what CI showed: with Vintage, Surefire dies on TestEngine with ID 'junit-jupiter' failed to discover tests; without it (and with #2140 on main), the suite is fine again.

So this PR should only keep the invoker path fix in value/processor/pom.xml. Once #2142 lands, there's nothing left in functional/pom.xml from this PR to revert.

Happy to adjust further if the fail()-injection check still doesn't show AutoValueTest running.

[cpovirk]

If I put a failure into com.google.auto.value.AutoValueTest.testEmpty and include the Surefire bump to 3.6.0, I get a failing run. We'll get this merged after the bump, unless @eamonnmcmanus again pulls the trick of actually reviewing in more depth than I did and finds something wrong along the way :)

[cpovirk]

Well, I had tested with the Failsafe version bump. I went back to test without that just to be safe, and I got what I assume is a random flake:

[INFO] [INFO] #1 retrying connecting to the daemon 
[INFO] [INFO] #2 retrying connecting to the daemon 
[INFO] [INFO] #3 retrying connecting to the daemon 
[INFO] [ERROR] Failed connecting to the daemon in 4 retries

I'll retest to be extra safe.

[cpovirk]

Proper error confirmed.