Manual pub roll

[goderbauer]

Automated roll in was failing with:

warning � The ability to import 'Source' indirectly is deprecated � dev/snippets/test/filesystem_resource_provider.dart:145:3 � deprecated_export_use
warning � The ability to import 'FileSource' indirectly is deprecated � dev/snippets/test/filesystem_resource_provider.dart:146:12 � deprecated_export_use

This change fixes the imports (see second commit).

[goderbauer]

@andrewkolos In this PR I was able to fix one of the failures from the put roll in #150450, but the tool_integration_tests remain unhappy. Do you know what the issue here is?

[andrewkolos]

This looks like a similar situation to #148911 (gradle being unable to version-solve dependencies)

I think the fix here would be to run (in bash/zsh)

find . -type d -name 'android' | dart dev/tools/bin/generate_gradle_lockfiles.dart --no-gradle-generation --no-exclusion

after you run flutter update-packages --force-upgrade

(source: #149342)

P.S. #149355 appears to be trying to automate this headache away

[andrewkolos]

I think the fix here would be to run (in bash/zsh)

find . -type d -name 'android' | dart dev/tools/bin/generate_gradle_lockfiles.dart --no-gradle-generation --no-exclusion

I tried this but ended up with an error coming from Gradle:

full output

If you would rather enter the files manually, just run `dart dev/tools/bin/generate_gradle_lockfiles.dart`,
enter the absolute paths to the app's android directory, then press CTRL-D.
If you don't wish to re-generate the settings.gradle, build.gradle, and gradle-wrapper.properties files,
add the flag `--no-gradle-generation`.
This tool automatically excludes a set of android subdirectories, defined at dev/tools/bin/config/lockfile_exclusion.yaml.
To disable this behavior, run with `--no-exclusion`.

Running without exclusion.
docs/platforms/android/build.gradle does not exist - skipping
examples/hello_world/android/build.gradle does not exist - skipping
Processing examples/layers/android
Unhandled exception:
ProcessException: > Task :gradle:compileJava NO-SOURCE
> Task :gradle:compileGroovy FAILED
1 actionable task: 1 executed

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':gradle:compileGroovy'.
> BUG! exception in phase 'semantic analysis' in source unit '/Users/andrewkolos/Documents/GitHub/flutter/packages/flutter_tools/gradle/src/main/groovy/app_plugin_loader.groovy' Unsupported class file major version 66

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 5s

  Command: /Users/andrewkolos/Documents/GitHub/flutter/examples/layers/android/gradlew :generateLockfiles
#0      exec (file:///Users/andrewkolos/Documents/GitHub/flutter/dev/tools/bin/generate_gradle_lockfiles.dart:202:5)
#1      main (file:///Users/andrewkolos/Documents/GitHub/flutter/dev/tools/bin/generate_gradle_lockfiles.dart:173:5)
#2      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:295:33)
#3      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:184:12)

Judging from Unsupported class file major version 66, I'm guessing there's some incompatibility between the version of java on my system's path and whatever version of Gradle is being used. Running java --version yields

openjdk 22.0.1 2024-04-16
OpenJDK Runtime Environment Zulu22.30+13-CA (build 22.0.1+8)
OpenJDK 64-Bit Server VM Zulu22.30+13-CA (build 22.0.1+8, mixed mode, sharing)

Perhaps I need an earlier JDK? cc @gmackall in case he has any insights.

[gmackall]

Perhaps I need an earlier JDK? cc @gmackall in case he has any insights.

Yes, that error means Gradle doesn't support that version of Java. I'd try with the java version in the engine (at something like /Users/mackall/development/engine/src/third_party/java/openjdk/Contents/Home/), which is Java 17. Gradle respects JAVA_HOME, so you can try setting that

[gmackall]

Also, I realized today that the script doesn't work right now for some tests that we have because they recently-ish switched to kotlin gradle files, so I put up #150471 - if you find that you run the script and are still running into lockfile issues that is probably the cause

[DanTup]

Is this PR redundant now? Looks like the changes were rolled in via #150585

[goderbauer]

Superseded by #150585. Closing.