1 |
On 06/01/2023 19.52, Yuan Liao (Leo) wrote: |
2 |
> While I warmly appreciate and welcome any effort to improve support |
3 |
> for Java build systems on Gentoo, I also wonder what functionality |
4 |
> ebuild authors who are creating a Java package might expect from an |
5 |
> eclass called "gradle.eclass". |
6 |
|
7 |
It is not strictly forbidden for an eclass to serve multiple use cases. |
8 |
However, there is an argument to separate the concerns into different |
9 |
eclasses (as we do already with other ecosystems). But we don't have |
10 |
those different concerns implemented right now. And there is IMHO a good |
11 |
reason this eclass should be called gradle.eclass: it provides basic |
12 |
functionality to discover a suitable gradle version and invoke gradle |
13 |
with sane defaults and in the idiomatic Gentoo way ("egradle <args>"). |
14 |
|
15 |
|
16 |
> I'm not doubting this eclass's usefulness -- to me, it looks like a |
17 |
> convenient eclass when a Gradle project's dependencies are vendored |
18 |
> and included in SRC_URI. |
19 |
|
20 |
The PR I mentioned migrates an openjfx ebuild from using its own gradle |
21 |
installation to the eclass [1]. And ::java has a ghidra ebuild [2] that |
22 |
uses gradle.eclass. Which was based on ::pentoo's ghidra ebuild with |
23 |
minor modifications to use the eclass. I recommend to look at the diff |
24 |
between the ::java version and ::pentoo version of the ghidra ebuild too. |
25 |
|
26 |
And the eclass, as is, is currently not only used for sideloaded |
27 |
dependencies. If you look at the openjfx ebuild then you will find that |
28 |
it consumes java libraries that are installed as Gentoo package |
29 |
(stringtemplate and hamcrest-core) and injects it into the Gradle build. |
30 |
|
31 |
|
32 |
> Specialized eclasses are totally fine as |
33 |
> we've already got plenty of them in the tree. But I think what an |
34 |
> average Java ebuild author often wants is an eclass with which they |
35 |
> can just declare all dependencies of the Gradle project in *DEPEND |
36 |
> variables, and rely on the default pkg_* and src_* functions from the |
37 |
> eclass to do the rest, with no or only minimal overrides necessary. |
38 |
> They might trust the eclass to introduce any Java dependencies |
39 |
> installed by Portage to Gradle, invoke the build system, and finally |
40 |
> install the JARs built. |
41 |
|
42 |
|
43 |
Yeah, that is what I also would prefer. And, in fact, this is done for |
44 |
many existing Java ebuilds. However, reality is that it is often not |
45 |
feasible to do so with modern Java build systems, as they switch from |
46 |
consuming Jar files to consuming Maven artifacts with POMs. I'd love to |
47 |
see an effort to remedy the situation and I actually believe the |
48 |
gradle.eclass provides basic functionality towards this, but the cruel |
49 |
reality is that we are far away from that (as far as I can tell) and |
50 |
currently do not have the manpower to make it happen. I would be happy |
51 |
to be proven wrong, though. |
52 |
|
53 |
Furthermore, the approach that the openjfx ebuild uses to inject |
54 |
libraries in the Gradle build is not generally applicable. IMHO the |
55 |
perfect solution would consists of a system-wide Maven repository, where |
56 |
Java ebuilds install their Jar files. And a robust way to tell Gradle |
57 |
(and Maven, …) to consume artifacts from such a system-wide Maven |
58 |
repository and a way to tell the build system to not perform any network |
59 |
activity. |
60 |
|
61 |
I think thin would be beneficial not only to Gentoo, but to other |
62 |
distributions too. But, again, it is a long way to get there. |
63 |
|
64 |
|
65 |
> Maybe we will be lucky enough to have such an eclass in the future. |
66 |
> But should we add a remark to the eclass's description to warn that |
67 |
> this might not be the generalized "gradle.eclass" suitable for |
68 |
> packaging most Gradle-based projects, if that is what people would |
69 |
> believe a "gradle.eclass" would do for them? |
70 |
|
71 |
I am not sure what such a warning is going to acomplish. But certainly, |
72 |
if "better" approaches are implemented, then our documentation should |
73 |
point them out. |
74 |
|
75 |
- Flow |
76 |
|
77 |
1: |
78 |
https://github.com/gentoo/gentoo/pull/28986/commits/808197948074c1582d3e3c7877d68cb9a6fa2f72 |
79 |
2: |
80 |
https://github.com/gentoo/java-overlay/blob/master/dev-util/ghidra/ghidra-10.2.2-r2.ebuild |