Re: [gentoo-dev] RFC: new gradle.eclass

[Florian Schmaus <flow@gentoo.org>]

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