| 1 |
While I warmly appreciate and welcome any effort to improve support |
| 2 |
for Java build systems on Gentoo, I also wonder what functionality |
| 3 |
ebuild authors who are creating a Java package might expect from an |
| 4 |
eclass called "gradle.eclass". |
| 5 |
|
| 6 |
I'm not doubting this eclass's usefulness -- to me, it looks like a |
| 7 |
convenient eclass when a Gradle project's dependencies are vendored |
| 8 |
and included in SRC_URI. Specialized eclasses are totally fine as |
| 9 |
we've already got plenty of them in the tree. But I think what an |
| 10 |
average Java ebuild author often wants is an eclass with which they |
| 11 |
can just declare all dependencies of the Gradle project in *DEPEND |
| 12 |
variables, and rely on the default pkg_* and src_* functions from the |
| 13 |
eclass to do the rest, with no or only minimal overrides necessary. |
| 14 |
They might trust the eclass to introduce any Java dependencies |
| 15 |
installed by Portage to Gradle, invoke the build system, and finally |
| 16 |
install the JARs built. |
| 17 |
|
| 18 |
Maybe we will be lucky enough to have such an eclass in the future. |
| 19 |
But should we add a remark to the eclass's description to warn that |
| 20 |
this might not be the generalized "gradle.eclass" suitable for |
| 21 |
packaging most Gradle-based projects, if that is what people would |
| 22 |
believe a "gradle.eclass" would do for them? |
| 23 |
|
| 24 |
Leo3418 |
| 25 |
|
| 26 |
On Fri, Jan 6, 2023 at 9:21 AM Florian Schmaus <flow@g.o> wrote: |
| 27 |
> |
| 28 |
> Happy new year everyone! |
| 29 |
> |
| 30 |
> I'd like to as for a review of an initial eclass for gradle. This is my |
| 31 |
> first eclass, so I am sure there is plenty to find. ;) |
| 32 |
> |
| 33 |
> The related github PR is https://github.com/gentoo/gentoo/pull/28986 |
| 34 |
> |
| 35 |
> - Flow |
| 36 |
> |
| 37 |
> |
Archives