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".
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. 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. 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? Leo3418 On Fri, Jan 6, 2023 at 9:21 AM Florian Schmaus <f...@gentoo.org> wrote: > > Happy new year everyone! > > I'd like to as for a review of an initial eclass for gradle. This is my > first eclass, so I am sure there is plenty to find. ;) > > The related github PR is https://github.com/gentoo/gentoo/pull/28986 > > - Flow > >
