Hi! I'm Rafael Girão from Portugal and I'm finishing a Bsc. in Computer Science & Engineering @ Técnico Lisboa this spring.

I will be applying to NixOS's Summer of Code this year. While I'll be applying to an existing idea, I would also like to propose an idea of my own:

Proposed idea: "nixpkgs Gradle tooling"

Problem summary

From my own mild research of nixpkgs, there seems to be no standard way of packaging Gradle applications as of today.
Each package author seems to choose their own approach to building Gradle-dependant software. Some examples:

• Some use hard-to-read perl scripts to mavenify Gradle dependencies, which then requires mangling the source's build files to work: openjfx, armitage , signald, key
• Some projects which just have dependencies that use Gradle simply ignore the problem by fetching pre-build JARs: Aeron-cpp

The problem with these methods is that they perform an entire build inside a fixed-output-derivation just to achieve the side effect of getting all project's dependencies cached locally. As a result, packages have weak reproducibility guarantees
and computational time is spent building the project twice (once for fetching dependencies and once for truly building it).

Proposal

Create tooling in nixpkgs to standardize Gradle packaging methods, similar to the tooling available for Maven projects:

• fetch a project's Gradle dependencies, e.g fetchGradleDeps
  • To avoid building the whole project inside a fixed-output-derivation, I propose using Gradle's new dependency verification feature, which fetches all project dependencies as a side-effect. I hope this approach also translates to stronger reproducibility guarantees.
• create a stdenv-based utility for building Gradle packages, e.g buildGradlePackage.
• (?) Convert existing Gradle software packages to use this new tooling.

Expected effort

Since I think this idea is very similar to nixpkgs pnpm tooling, I believe it's a medium (175h) with a rating of hard.

Please let me know your thoughts on this idea.

Thanks!

Intro

This issue is to take over the conversation from NixOS/foundation#115 and avoid cluttering the original repo.

I guess here we can discuss all matters and decisions related to this repo.

My suggestion and conversation startes

Here's a few small-ish ideas to get the conversation kicking:

1 - turn the ideas file into a directory tree

Right now the Ideas file it's just a markdown file, I think it would be better if we make it a directory, with a nice README.md file (with explanation, example, requirements, etc..) and then each new idea can be its own directory. (with a README.md file, images, code examples and all needed other artifacts)

2 - make the readme more "jazzy"

I'll try to make the README more colorful/enticing for possible new-comers (see an example about what I mean HERE .. just an image or two maybe)

3 - create a Matrix room

We should try to foster collaboration and community as much as possible as it's at the heart of all this kind of events.
So I'm proposing we should create a few Matrix rooms like:

• #gsoc-staff:nix.org -> for the organising staff
• #gsoc-mentors:nix.org -> for the mentors and the staff
• #gsoc:nix.org -> for anybody that is interested, mentee, mentors, staff, students, curious ppl, etc..

outro

Hopefully that's enough of a conversation starter 😬

• Seems like it will cause lots of merge conflicts
• We could just use issues; that's what I think I've seen other projects do?

Hello!
I want to suggest to include the RFC 132 implementation onto GSoC.

NixOS/rfcs#132