Hi Ryan- Nice work on the Gradle 7.4 upgrade!
I know first-hand how challenging this effort is since I am (currently) going through the same exercise with all the Spring for Apache Geode projects. In fact, minimally, Gradle 7.3 is required to build with Java 17 [1]. Be careful when switching pre-Gradle 7 "compile" dependencies to "compileOnly" as those dependencies won't show up on the runtime classpath. In certain cases, those dependencies may need to be "implementation" scoped, or even "api" scoped if the Geode module is a "Java Library" (declared by the Java Library Gradle Plugin [2]), and the module's declared dependencies should be exported as part of the library API. geode-core appropriately has several of these (for example, here<https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L248> [3] and here<https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L260> [4]; this dependency<https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L190> [5] arguably should not be exposed as it is an "implementation" detail and not strictly something users require to program against the Geode (core) API; A good example of "compileOnly" dependencies can be seen here<https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L203-L205> [6]). Some of the other scope names have changed as well, e.g. "runtime" to "runtimeOnly". Anyway, more information about dependency scopes can be found here<https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management> [7] and here<https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation> [8]. Regards, John [1] https://docs.gradle.org/7.3.3/release-notes.html [2] https://docs.gradle.org/current/userguide/java_library_plugin.html [3] https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L248 [4] https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L260 [5] https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L190 [6] https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L203-L205 [7] https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management [8] https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation ________________________________ From: Ryan Gardner <ryeb...@gmail.com> Sent: Wednesday, February 9, 2022 7:32 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Update the build to use Gradle 7.4 Hello, Up-front disclaimer: I'm not a Gradle expert - but I spent a little time poking around at what it would take to upgrade the build to go from Gradle 6.8 -> Gradle 7.4 Previous efforts to clean up Gradle 7 deprecation warnings made it fairly straightforward - in the end it seems there were only a few changes needed. - An internal gradle class for the temporary file creation changed it's package location in Gradle 7 - A couple places had references to the now-removed "compile" classpath and needed to be replaced with "compileOnly" - Gradle 7 gets upset about tasks that have implicit dependencies between them - some of the tasks such as the combined report generation needed to have a "dependsOn" added to it - The Geode build has a custom version of the "DefaultTaskExecutor" - Gradle made some minor changes to the DefaultTaskExecutor in version 7.4. I made those same changes in the RepeatedTaskExecutor On my local machine the build runs the same as it does on the 6.8 version - there are some tests that fail due to bind exceptions. I just created a draft pull request - like I mentioned before, I'm not the world's leading expert in Gradle so there may be a better way to make some of the same kind of changes. I created a draft pull request so that it might at least serve as a starting point when someone else wants to take a look at this. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7351&data=04%7C01%7Cjblum%40vmware.com%7C0a5b49c75996410c6b9508d9ebe17e68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637800175994899287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YYkUU3PJFxkj57VnQsWzvA%2ByElUqFTjYlXEaB5NvMqk%3D&reserved=0 I didn't see a JIRA issue directly associated with this, it's sort of related to GEODE-9161 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9161&data=04%7C01%7Cjblum%40vmware.com%7C0a5b49c75996410c6b9508d9ebe17e68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637800175994899287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=e1JVs6fdnqQlaqdEDssP%2B022qbqzlEkVb7QtZXTv3E8%3D&reserved=0> since it gets rid of the deprecation warnings. Hope it's helpful, Ryan
