Fix usage of deprecated Gradle APIs scheduled to be removed in Gradle 9.0

[breskeby]

Description

With Gradle 9.0 approaching soon, this fixes incompatibilities with Gradle 9.0 by fixing two types of deprecated api usage in the build logic:

1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated
2. The Project.exec(Closure) method has been deprecated.

[github-actions]

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

[dweiss]

Right... This is among those things I mentioned that I don't understand - perhaps there are benefits to configuration caching or other advanced features... but overall it's a lot more boilerplate for something that is conceptually dead simple and that should remain simple. Eh.

[breskeby]

Right... This is among those things I mentioned that I don't understand - perhaps there are benefits to configuration caching or other advanced features... but overall it's a lot more boilerplate for something that is conceptually dead simple and that should remain simple. Eh.

One problem that gradle is suffering from is, all the freedom it had given in the (groovy) DSL implementation in its early days. which makes it hard to move forward with making substantial progress on optimizing the gradle configuration phase.

In this example just everything was kind of slammed into the project object (type Project) which is mutable by contract which makes optimizations way harder. Since ~2 major releases, Gradle keeps slowly deprecating and cutting back on this.

Furthermore some of this "magic" like the way Conventions had been implemented back then makes IDE support way harder.

Currently almost all of the build logic is jammed into the gradle files. The approach Gradle recommends usually is to keep convention plugins and build scripts small and only contain conventions and a few configurations and keep more complex implementation logic in testable binary plugin and task implementation. "Weired" boilerplate like the "InjectedExec" class I added as part of this PR I consider workarounds to achieve stuff in in build scripts that should probably better live in this binary (plain java?) implementation. There the boilerplate is usually minimal and not as bad as when staying with gradle files only.

[dweiss]

One problem that gradle is suffering from is, all the freedom it had given in the (groovy) DSL implementation in its early days.

Thanks. It's subjective, I know, but I have been a user of gradle since these early days and that freedom... I miss it. My subjective gut feeling is also that in the early days - when stripped of all the added-on features like build caches, configuration caches, etc. - gradle startup wasn't even a problem. My memory may be playing tricks on me but I do miss the simplicity of the early days (when it was basically ant tasks + groovy to configure everything).