On 07/01/2023 05.29, Sam James wrote:
On 6 Jan 2023, at 17:20, Florian Schmaus <[email protected]> wrote:
Signed-off-by: Florian Schmaus <[email protected]>
---
eclass/gradle.eclass | 149 +++++++++++++++++++++++++++++++++++++++++
eclass/tests/gradle.sh | 62 +++++++++++++++++
2 files changed, 211 insertions(+)
create mode 100644 eclass/gradle.eclass
create mode 100755 eclass/tests/gradle.sh
diff --git a/eclass/gradle.eclass b/eclass/gradle.eclass
[...]
+
+# @ECLASS_VARIABLE: EGRADLE_MIN
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Minimum required gradle version.
+
+# @ECLASS_VARIABLE: EGRADLE_MAX_EXCLUSIVE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# First gradle version that is not supported.
+
+# @ECLASS_VARIABLE: EGRADLE_EXACT_VER
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The exact required gradle version.
+
It feels a pity to not use the now-somewhat standard
PYTHON_COMPAT/LUA_COMPAT-style API.
Is there a reason not to?
If it doesn't fit how Gradle versioning works / the
number of targets is likely to be far too high,
It's fine as-is.
The _COMPAT-style API would work for Java LTS versions, but not for fast
moving targets like Gradle versions.
Gradle has overall a good compatibility story, breaking changes are
typically just introduced in new major versions. But sometimes you need
a particular Gradle version range, like [6.2,6.8) due the mixins of
Gradle plugins.
I expect that the number of Java projects that use Gradle will continue
to grow. Because of that we probably need to provide a diverse range of
Gradle versions.
- Flow
