Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 915114

Summary: dev-java/gradle: new package, Java build system
Product: Gentoo Linux Reporter: Kyle Rabago <rabagok07>
Component: New packagesAssignee: Default Assignee for New Packages <maintainer-wanted>
Status: UNCONFIRMED ---    
Severity: enhancement CC: flow, gentoo, java
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=777609
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 777609    

Description Kyle Rabago 2023-10-03 14:22:41 UTC
As stated in the summary, add, if possible a gradle ebuild to build gradle from source 

Reproducible: Always




If not possible could work be done to make more non-bin packages such as for things like kotlin, etc.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-10-03 14:24:18 UTC
I think Flow has some stuff in progress in the Java overlay right now combined with an eclass for this.

Surprised there's not some bug already for this though.
Comment 2 Kyle Rabago 2023-10-03 15:19:52 UTC
As far as I know all of the gradle (src built) ebuilds I have tried all fail for some reason or another even in the flow repo or java repo
Comment 3 Volkmar W. Pogatzki 2023-10-03 17:35:00 UTC
Maybe a suitable task for next gsoc?
Comment 4 Florian Schmaus gentoo-dev 2023-10-03 20:12:25 UTC
Back in 2013, when I started working on the gradle ebuilds and associated packages, like eselect-gradle, I tried to create source based ebuilds for gradle. That is why, for example, eselect-gradle, is designed so that also non gradle-bin binaries are selectable.

However, I never got source-based gradle ebuilds to work, and the gradle-bin ebuilds are sufficiently good enough for me. Especially considering that we are talking about a Java bytecode, which is going to get compiled at runtime anyway. 

That said, I would welcome source-based gradle ebuilds. The main problem is always the provisioning of the dependencies. Fortunately, ::pentoo has there something for ghidra, which we could look into re-using for source-based gradle ebuilds. Although, I'd like to add, that the task strikes me as a bit to advanced for GSoC.
Comment 5 Kyle Rabago 2023-11-01 14:03:05 UTC
(In reply to Florian Schmaus from comment #4)
> Back in 2013, when I started working on the gradle ebuilds and associated
> packages, like eselect-gradle, I tried to create source based ebuilds for
> gradle. That is why, for example, eselect-gradle, is designed so that also
> non gradle-bin binaries are selectable.
> 
> However, I never got source-based gradle ebuilds to work, and the gradle-bin
> ebuilds are sufficiently good enough for me. Especially considering that we
> are talking about a Java bytecode, which is going to get compiled at runtime
> anyway. 
> 
> That said, I would welcome source-based gradle ebuilds. The main problem is
> always the provisioning of the dependencies. Fortunately, ::pentoo has there
> something for ghidra, which we could look into re-using for source-based
> gradle ebuilds. Although, I'd like to add, that the task strikes me as a bit
> to advanced for GSoC.

 As far as I know building gradle is with gradle as far as the offical gradle docs on building from the github, however this build doesnt take into account alot of things such as dependecies as gradle will fetch them automatically unless specefied otherwise at least to my knowledge