Hello everyone, I'm Hermes, I'm interested in cont...

# gsoc

[Chisom Chigoziri]

Hello everyone,
I'm Hermes, I'm interested in contributing to the Clean and actionable reporting for Gradle code quality plugins for Kotlin project for GSoC 2025.

Although most of my technical skills are in Web Development, I've recently gotten into Kotlin + Native Android Development and have been actively improving my skills on said technologies. I aim to use GSoC as a medium to improve on my skills in Kotlin and properly get into the open source ecosystem by integrating one or more of Kotlin's code quality plugins with the new Problems API.

Currently, my assumption is that the basic idea is; the contributor will choose one of code quality plugins and integrate the Problems API into it which would entail one or more PRs to its repository until the Problems API is fully integrated.
Is this a correct assumption?

My plans at the moment include getting familiar with the Problems API and the going through some of the code quality plugins.

[Oleg Nenashev]

Thanks for your interest!

[Oleg Nenashev]

To confirm, your assumption is correct. You are free to choose one or multiple plugins in your proposal

[Chisom Chigoziri]

@Oleg Nenashev I checked out some of the code quality plugins and the Problems API.
I came to the conclusion that the basic idea is to build a custom reporter for these code quality plugins; a reporter that uses the Problems API to report linting issues.
What do you think?

[Oleg Nenashev]

In principle, it makes sense. It is similar to how, for example, the Checks API Plugin for Jenkins was born https://plugins.jenkins.io/checks-api/

[Oleg Nenashev]

"Makes sense" means that it is something I would like to see. The same time, I would normally expect most of static analysis capabilities to be embedded in the core API in the future, but experimenting with them in a plugin Is the right approach?

[Chisom Chigoziri]

I would normally expect most of static analysis capabilities to be embedded in the core API in the future

Hmm, could you please clarify what you mean here?

[Chisom Chigoziri]

From what I've understood so far, It seems implementing the Problems API would be done in a Gradle context so for example in a gradle plugin for ktlint?

[Chisom Chigoziri]

Are we expected to make the changes to the gradle plugins or perhaps it would be preferred to build another gradle plugin that works alongside the more robust gradle plugins, where this new gradle plugin would be responsible for reporting lint issues via the Problems API?
@Oleg Nenashev

[Oleg Nenashev]

My recommendations would be to contribute to the existing plugins, unless there is any blocker for such an approach

[Chisom Chigoziri]

@Oleg Nenashev @Balint Hegyi With regards to the "Clean and actionable reporting for Gradle code quality plugins for Kotlin" project idea, my focus is on implementing the Problems API into the Gradle plugins of ktlint and detekt. What project size would be appropriate in the proposal submission form?

[Chisom Chigoziri]

Hello, I made a draft of my proposal and was wondering if I could get some feedback.
https://docs.google.com/document/d/1C7-A-iPZp77TPRt-euoOwtEsRnhoDqYBLSH1tYwB_FA/edit?usp=sharing
@Balint Hegyi @Oleg Nenashev

[Oleg Nenashev]

Thank you. Access to commenting would be nice

[Chisom Chigoziri]

Yeah I've corrected it

[Chisom Chigoziri]

Hello, What do you think about my proposal draft? @Oleg Nenashev

[Oleg Nenashev]

Thanks for setting expectations about your availability, it always helps. Are you also on the Gradle Community Slack? I would probably share https://github.com/TruePadawan/ktlint-problems-plugin and discuss it with the team right away

[Oleg Nenashev]

CC @jlleitschuh ^, just in case you are still on this Slack 🙂

[Chisom Chigoziri]

Yeah I'm in the Gradle Community Slack

[Oleg Nenashev]

Let's proceed there with tech details