Re: [gentoo-dev] [PATCH] gradle.eclass: add new eclass

[Florian Schmaus <flow@gentoo.org>]

On 07/01/2023 05.29, Sam James wrote:
> 
> 
>> On 6 Jan 2023, at 17:20, Florian Schmaus <flow@gentoo.org> wrote:
>>
>> Signed-off-by: Florian Schmaus <flow@gentoo.org>
>> ---
>> 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