https://gradle.com/ logo
Join Slack
Powered by
# problems-api
  • o

    Oleg Nenashev

    11/06/2024, 10:15 AM
    set the channel description: Anything about Gradle Problems API and modern error reporting and propagation for Gradle. Roadmap Item: https://github.com/gradle/build-tool-roadmap/issues/49
  • s

    Slackbot

    11/06/2024, 10:22 AM
    message has been deleted
  • s

    Slackbot

    11/06/2024, 4:26 PM
    message has been deleted
  • d

    Donát Csikós

    11/07/2024, 12:40 PM
    Hello everyone! 👋
  • d

    Donát Csikós

    11/07/2024, 12:41 PM
    set the channel description: Anything about Gradle Problems API and modern error reporting and propagation for Gradle. Roadmap: https://github.com/orgs/gradle/projects/31/views/1?filterQuery=-status%3A%22Released%22+tracked-by%3A%22gradle%2Fbuild-tool-roadmap%2349%22
  • d

    Donát Csikós

    11/07/2024, 12:43 PM
    set the channel description: Anything about Gradle Problems API and modern error reporting and propagation for Gradle. Roadmap: https://tinyurl.com/gr-problems
  • a

    Arthur McGibbon

    11/07/2024, 1:25 PM
    Hi. Are there plans to use the problems api to emit/report errors/warnings in other built-in languages beside Java (e.g. Groovy, Scala)?
    b
    • 2
    • 1
  • a

    Arthur McGibbon

    11/07/2024, 1:32 PM
    Are there any plans to re-emit problems from up-to-date tasks? I.e. if I compile a java project which shows warnings on CLI, the next time I compile it the task will say up-to-date and no warnings will be displayed even though they still exist in the code. It would be very nice if the Java warnings shown on
    gradlew clean classes
    were re-shown on subsequent
    gradlew classes
    even when no code has changed. This matters more when there are many subprojects and changing one and recompiling means that all warnings associated with the unchanged projects are lost until
    clean
    or
    --rerun-tasks
    is used.
    b
    • 2
    • 3
  • j

    Javi

    12/11/2024, 12:18 PM
    Does the problems APIs support other outputs than HTML? Is sarif supported or on the roadmap?
    ➕ 1
    d
    • 2
    • 10
  • j

    Javi

    01/07/2025, 3:13 PM
    Cross-posting here: https://gradle-community.slack.com/archives/CAHSN3LDN/p1736262758991409?thread_ts=1736260845.634329&cid=CAHSN3LDN
    d
    • 2
    • 1
  • r

    ritesh singh

    02/28/2025, 2:08 PM
    👋 Just getting started with problems api. Was wondering the scope it, can it be used to catch any errors thrown during the build by any task.
    p
    d
    • 3
    • 7
  • c

    ChAoS - UnItY

    03/05/2025, 10:10 AM
    Hey guys, I'm excited to look into Clean and actionable reporting for Gradle code quality plugins for Kotlin project in GSoC 2025 chapter, is there any related discussions or issues to learn more about this proposal? thanks!
    d
    • 2
    • 1
  • c

    Chisom Chigoziri

    03/24/2025, 9:30 AM
    Hello, I've been trying to integrate the Problems API into a simple gradle plugin project but I'm having some issues. I use the ProblemReporter to report problems in a particular task, when I run the task, I get the html problems report but I don't see the reported problems in IntelliJ, is that expected behaviour? I was under the assumption that clients of the Tooling API like IDEs will pick up the reported problems and do something with them, in this case I thought IntelliJ would show the reported problems in the Problems tab or something
    b
    • 2
    • 6
  • v

    Vanessa Johnson

    03/25/2025, 12:28 PM
    Hi, I was in the general Kotlin slack and am interested in the Clean and Actionable reporting for Gradle code quality plugins for Kotlin. I already wrote up my proposal and would like some early feedback if possible! I will reply in thread with my doc.
    🙌 2
    o
    r
    +2
    • 5
    • 9
  • o

    Oleg Nenashev

    05/16/2025, 7:57 PM
    Hi @Vanessa Johnson! Welcome to Google Summer of Code, and looking forward to working with you together with @Reinhold Degenfellner @Donát Csikós and hopefully a few other contributors! How is your availability in the coming 2 weeks during the community bonding? It would be nice to schedule a first team meeting so that we could align on the communication channels and the first steps for the coding phase
    v
    r
    d
    • 4
    • 21
  • o

    Oleg Nenashev

    05/27/2025, 12:37 PM
    So, notes from the call: 1. We start from Problems API in the Detekt Plugin, as per proposal 2. Good first steps: a. Update the project page b. Create GitHub issue(s) for the first deliverables c. Create meeting invites / docs for meeting notes d. Try building Detekt plugin and the repo locally so that there are no surprises 3. Scope for the first patch: ◦ Feature itself - as in the project proposal ◦ Test coverage - some roundtrip test for Problems API would be useful ◦ Nice2have: Documentation - if we have special use requirements ◦ Some demonstration of things working - Currently we have only HTML report as a consumer, but there is ongoing work on CLI and some opportunities for GitHub Checks CC @Vanessa Johnson @Donát Csikós @Reinhold Degenfellner - let me know if I missed something
  • i

    Ivan CLOVIS Canet

    06/04/2025, 3:27 PM
    Hi! I'm interested in creating a plugin to export the Problems API to GitLab's merge request UI. I've already created a few plugins and I'm familiar with the GitLab format, so that shouldn't be a problem. Ideally, this would take the form of a Gradle (settings?) plugin that when applied, listens to all emitted problems, and at the end of the build generates the JSON report expected by GitLab. However, I don't understand how a Gradle plugin can access the reported errors. The documentation mentions:
    Tooling API clients can access detailed problem reports associated with build failures via the
    Failure
    object on the root build operation. To receive these reports, the clients must register a progress listener for the
    OperationType.ROOT
    operation type. The progress listener callback should then check if the operation result is of type
    FailureResult
    , and then it can access the associated problems via
    Failure.getProblems()
    .
    However, this only applies to those using the Tooling API, whereas my project would be a Gradle plugin itself. How can I access the reported problems from a Gradle plugin? For convenience (to avoid having it to be declared in each project), it would be better if I could access the reported problems directly from a settings plugin.
    p
    • 2
    • 4
  • v

    Vanessa Johnson

    06/10/2025, 10:35 AM
    Hi @Oleg Nenashev @Donát Csikós @Reinhold Degenfellner , I don’t think our meeting today is necessary but I do have some follow up questions that I’ll put in this thread 🧵
    o
    r
    • 3
    • 10
  • v

    Vanessa Johnson

    07/01/2025, 2:42 AM
    Thanks! Also do I need any specific permissions to push to the repo? I was having some issues pushing up my branch yesterday but it could really be on my end too. Sorry for the late message. I just send this message in the channel and not in the thread
    o
    • 2
    • 1
  • o

    Oleg Nenashev

    07/01/2025, 12:42 PM
    @Vanessa Johnson https://github.com/detekt/detekt/blob/main/detekt-gradle-plugin/src/functionalTest/kotlin/dev/detekt/gradle/plugin/DetektBasePluginSpec.kt - for smoke test example
    • 1
    • 1
  • o

    Oleg Nenashev

    07/08/2025, 10:06 AM
    @Vanessa Johnson did you have a chance to create your first pull request?
    v
    • 2
    • 10
  • o

    Oleg Nenashev

    07/08/2025, 10:07 AM
    FWIW I am on vacation but can join the call if needed. It is better to discuss on the chat though
  • v

    Vanessa Johnson

    07/11/2025, 2:03 PM
    @Oleg Nenashev @Reinhold Degenfellner I’m running into this error I haven’t been able to fix. I’ve tried a few potential solutions but that doesn’t seem to be the way to go because I would no longer see the “Incubating” line. Pictures will be in 🧵
    o
    • 2
    • 6
  • o

    Oleg Nenashev

    07/15/2025, 11:50 AM
    I will be a few minutes late to the meeting