This is in preparation of executing these tests on GH-hosted M1 runners,
where we need to have architecture-specific path handling.
It's nicer to fix all of this in one place (the helper), than to run around
fixing individual tests.
I've been investigating moving the Java integration tests to a
GH-hosted macos runner, instead of a self-hosted one.
This test is not compatible with a GH-hosted runners Java setup.
It is also not compatible to being exposed to JAVA_21_HOME_X64 variable yet.
This PR fixes both issues.
They were all failing for me like:
[autobuild] /home/ian/code/dev/target/codeql-java-integration-tests/ql/java/ql/integration-tests/all-platforms/java/android-sample-old-style-no-wrapper/project/src/main/AndroidManifest.xml:5: Error: Main must extend android.app.Activity [Instantiatable]
[autobuild] <activity android:name="Main" android:exported="true">
[autobuild] ~~~~
[autobuild] Explanation for issues of type "Instantiatable":
[autobuild] Activities, services, broadcast receivers etc. registered in the manifest
[autobuild] file (or for custom views, in a layout file) must be "instantiatable" by
[autobuild] the system, which means that the class must be public, it must have an
[autobuild] empty public constructor, and if it's an inner class, it must be a static
[autobuild] inner class.
I'm not sure why it works on CI but not locally, but either way this
works around the issue.
Maven 3.9.1 changes the format of the error message this test is looking for (though it still matches the target regex). Use the Maven wrapper to avoid such sensitivity to the precise version present in the environment.
This adds a single plain Gradle project that uses a modern Kotlin build script (i.e. settings.gradle.kts and no build.gradle.kts), plus basic Android samples exercising the possible permutations of: (old vs. new-style build script, Groovy vs. Kotlin build script, wrapper present vs. absent)
Old vs. new style tests our recognition of different cues that this is likely a Droid project and requires `gradle assemble` not `gradle testClasses` (the example given at https://developer.android.com/studio/build/#top-level changed style as of plugin version ~7.3.0).
Groovy vs. Kotlin build script language checks that the regexes recognising Android dependencies and versions work for both build script kinds.
Wrapper present vs. absent exercises the autobuilder logic that guesses an appropriate Gradle version and sets it up in the event the Gradle wrapper isn't provided.
