From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 402EE15800F for ; Sat, 7 Jan 2023 10:58:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 073D8E0826; Sat, 7 Jan 2023 10:58:30 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AEFFEE07E2 for ; Sat, 7 Jan 2023 10:58:29 +0000 (UTC) Message-ID: <3b1aa701-c0b8-cde2-3590-6ea629b7214f@gentoo.org> Date: Sat, 7 Jan 2023 11:58:24 +0100 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [gentoo-dev] [PATCH] gradle.eclass: add new eclass Content-Language: en-US To: Sam James , gentoo-dev@lists.gentoo.org References: <20230106172051.274199-1-flow@gentoo.org> <20230106172051.274199-2-flow@gentoo.org> <44DF820D-602C-4DE6-8BE7-B9E3A858B53D@gentoo.org> From: Florian Schmaus In-Reply-To: <44DF820D-602C-4DE6-8BE7-B9E3A858B53D@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 61a9252b-f638-44c5-b5d7-d58c68f12167 X-Archives-Hash: 1bf7a3581da3383f8e058dafd5f3fca7 On 07/01/2023 05.29, Sam James wrote: > > >> On 6 Jan 2023, at 17:20, Florian Schmaus wrote: >> >> Signed-off-by: Florian Schmaus >> --- >> 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