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 <args>").
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)