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 DB97315800F for ; Fri, 6 Jan 2023 19:41:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 872D4E086D; Fri, 6 Jan 2023 19:40:57 +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) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 44B54E0863 for ; Fri, 6 Jan 2023 19:40:57 +0000 (UTC) Message-ID: <3d90a6fa-f03e-3f41-7152-cec5a527465e@gentoo.org> Date: Fri, 6 Jan 2023 20:40:37 +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] RFC: new gradle.eclass Content-Language: en-US To: gentoo-dev@lists.gentoo.org References: <20230106172051.274199-1-flow@gentoo.org> From: Florian Schmaus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: e084e6ca-cfc3-46d2-86a4-71d1c6da8157 X-Archives-Hash: 79d7a47c51ef4ecd656928f76f26e98e On 06/01/2023 19.52, Yuan Liao (Leo) wrote: > While I warmly appreciate and welcome any effort to improve support > for Java build systems on Gentoo, I also wonder what functionality > ebuild authors who are creating a Java package might expect from an > eclass called "gradle.eclass". It is not strictly forbidden for an eclass to serve multiple use cases. However, there is an argument to separate the concerns into different eclasses (as we do already with other ecosystems). But we don't have those different concerns implemented right now. And there is IMHO a good reason this eclass should be called gradle.eclass: it provides basic functionality to discover a suitable gradle version and invoke gradle with sane defaults and in the idiomatic Gentoo way ("egradle "). > I'm not doubting this eclass's usefulness -- to me, it looks like a > convenient eclass when a Gradle project's dependencies are vendored > and included in SRC_URI. The PR I mentioned migrates an openjfx ebuild from using its own gradle installation to the eclass [1]. And ::java has a ghidra ebuild [2] that uses gradle.eclass. Which was based on ::pentoo's ghidra ebuild with minor modifications to use the eclass. I recommend to look at the diff between the ::java version and ::pentoo version of the ghidra ebuild too. And the eclass, as is, is currently not only used for sideloaded dependencies. If you look at the openjfx ebuild then you will find that it consumes java libraries that are installed as Gentoo package (stringtemplate and hamcrest-core) and injects it into the Gradle build. > Specialized eclasses are totally fine as > we've already got plenty of them in the tree. But I think what an > average Java ebuild author often wants is an eclass with which they > can just declare all dependencies of the Gradle project in *DEPEND > variables, and rely on the default pkg_* and src_* functions from the > eclass to do the rest, with no or only minimal overrides necessary. > They might trust the eclass to introduce any Java dependencies > installed by Portage to Gradle, invoke the build system, and finally > install the JARs built. Yeah, that is what I also would prefer. And, in fact, this is done for many existing Java ebuilds. However, reality is that it is often not feasible to do so with modern Java build systems, as they switch from consuming Jar files to consuming Maven artifacts with POMs. I'd love to see an effort to remedy the situation and I actually believe the gradle.eclass provides basic functionality towards this, but the cruel reality is that we are far away from that (as far as I can tell) and currently do not have the manpower to make it happen. I would be happy to be proven wrong, though. Furthermore, the approach that the openjfx ebuild uses to inject libraries in the Gradle build is not generally applicable. IMHO the perfect solution would consists of a system-wide Maven repository, where Java ebuilds install their Jar files. And a robust way to tell Gradle (and Maven, …) to consume artifacts from such a system-wide Maven repository and a way to tell the build system to not perform any network activity. I think thin would be beneficial not only to Gentoo, but to other distributions too. But, again, it is a long way to get there. > Maybe we will be lucky enough to have such an eclass in the future. > But should we add a remark to the eclass's description to warn that > this might not be the generalized "gradle.eclass" suitable for > packaging most Gradle-based projects, if that is what people would > believe a "gradle.eclass" would do for them? I am not sure what such a warning is going to acomplish. But certainly, if "better" approaches are implemented, then our documentation should point them out. - Flow 1: https://github.com/gentoo/gentoo/pull/28986/commits/808197948074c1582d3e3c7877d68cb9a6fa2f72 2: https://github.com/gentoo/java-overlay/blob/master/dev-util/ghidra/ghidra-10.2.2-r2.ebuild